﻿1
00:00:01,090 --> 00:00:03,210
‫Instruktur: Sama seperti di

2
00:00:03,210 --> 00:00:05,810
‫bagian sebelumnya, sebelum kita menyelami teknologi

3
00:00:05,810 --> 00:00:08,590
‫baru, mari kita pelajari apa itu semua.

4
00:00:08,590 --> 00:00:12,180
‫Jadi dalam hal ini, mari kita pelajari apa sebenarnya

5
00:00:12,180 --> 00:00:14,750
‫MongoDB itu, cara kerjanya, dan

6
00:00:14,750 --> 00:00:18,600
‫tinjauan singkat tentang perbandingannya dengan database yang lebih tradisional.

7
00:00:18,600 --> 00:00:21,340
‫Dan mari kita mulai dengan gambaran sederhana.

8
00:00:21,340 --> 00:00:24,830
‫Jadi MongoDB jelas merupakan database, dan

9
00:00:24,830 --> 00:00:27,870
‫itu disebut database NoSQL.

10
00:00:27,870 --> 00:00:30,930
‫Sekarang beberapa orang juga mengatakan Tidak S Q

11
00:00:30,930 --> 00:00:34,240
‫L, tapi saya akan terus mengatakan "tidak ada sekuel", oke?

12
00:00:34,240 --> 00:00:37,010
‫Sekarang, jenis database lainnya,

13
00:00:37,010 --> 00:00:40,620
‫yang lebih tradisional, adalah database relasional,

14
00:00:40,620 --> 00:00:43,760
‫yang sering dibandingkan dengan NoSQL.

15
00:00:43,760 --> 00:00:48,330
‫Bagaimanapun, di Mongo, yang juga bisa kita katakan sebagai ganti

16
00:00:48,330 --> 00:00:52,570
‫MongoDB, setiap database dapat berisi satu atau lebih koleksi.

17
00:00:52,570 --> 00:00:55,100
‫Jadi, jika Anda benar-benar berasal

18
00:00:55,100 --> 00:00:58,530
‫dari salah satu sistem basis data relasional yang

19
00:00:58,530 --> 00:01:02,760
‫lebih tradisional ini, Anda dapat menganggap kumpulan sebagai tabel data.

20
00:01:02,760 --> 00:01:05,520
‫Kemudian, setiap koleksi dapat berisi satu

21
00:01:05,520 --> 00:01:09,130
‫atau lebih struktur data yang disebut dokumen, dan

22
00:01:09,130 --> 00:01:11,870
‫sekali lagi, dalam database

23
00:01:11,870 --> 00:01:15,380
‫relasional, dokumen akan menjadi baris dalam tabel.

24
00:01:15,380 --> 00:01:17,770
‫Jadi setiap dokumen berisi data

25
00:01:17,770 --> 00:01:20,600
‫tentang satu entitas tunggal, misalnya, satu

26
00:01:20,600 --> 00:01:24,870
‫posting blog atau satu pengguna atau satu ulasan, atau

27
00:01:24,870 --> 00:01:26,780
‫apa pun, sebenarnya.

28
00:01:26,780 --> 00:01:29,030
‫Anda mengerti maksudnya, kan?

29
00:01:29,030 --> 00:01:32,270
‫Sekarang koleksinya seperti struktur induk yang

30
00:01:32,270 --> 00:01:34,730
‫berisi semua entitas ini.

31
00:01:34,730 --> 00:01:38,120
‫Misalnya, koleksi blog untuk semua

32
00:01:38,120 --> 00:01:41,730
‫posting, koleksi pengguna, atau koleksi ulasan.

33
00:01:41,730 --> 00:01:44,060
‫Dan Anda juga dapat melihat di sini

34
00:01:44,060 --> 00:01:47,740
‫bahwa dokumen tersebut memiliki format data yang sangat mirip dengan JSON,

35
00:01:47,740 --> 00:01:49,810
‫yang akan membuat pekerjaan kita

36
00:01:49,810 --> 00:01:52,520
‫jauh lebih mudah ketika kita mulai menangani dokumen-dokumen ini.

37
00:01:52,520 --> 00:01:55,180
‫Dan tentunya kita akan banyak membicarakan hal

38
00:01:55,180 --> 00:01:58,543
‫ini nanti, tapi untuk sekarang, mari kita pelajari fitur-fitur utama Mongo.

39
00:01:59,460 --> 00:02:02,260
‫Jadi, menurut situs web MongoDB,

40
00:02:02,260 --> 00:02:05,990
‫MongoDB adalah database dokumen dengan skalabilitas dan

41
00:02:05,990 --> 00:02:08,330
‫fleksibilitas yang Anda inginkan,

42
00:02:08,330 --> 00:02:12,200
‫dan dengan kueri dan pengindeksan yang Anda butuhkan.

43
00:02:12,200 --> 00:02:14,710
‫Sekarang, kedengarannya agak berlebihan, jadi mari

44
00:02:14,710 --> 00:02:17,503
‫kita coba memahami apa artinya ini sebenarnya.

45
00:02:18,490 --> 00:02:23,250
‫Jadi, seperti yang kita lihat sebelumnya, MongoDB adalah database berbasis dokumen,

46
00:02:23,250 --> 00:02:25,750
‫sehingga menyimpan data dalam dokumen

47
00:02:25,750 --> 00:02:29,660
‫yang merupakan struktur data berpasangan nilai bidang seperti JSON.

48
00:02:29,660 --> 00:02:33,020
‫Jadi sekali lagi, ini menyimpan data dalam dokumen

49
00:02:33,020 --> 00:02:34,840
‫ini, bukan baris dalam

50
00:02:34,840 --> 00:02:37,530
‫tabel seperti di database relasional tradisional.

51
00:02:37,530 --> 00:02:39,930
‫Oleh karena itu database NoSQL

52
00:02:39,930 --> 00:02:42,190
‫dan bukan yang relasional.

53
00:02:42,190 --> 00:02:45,690
‫Selain itu, MongoDB memiliki skalabilitas bawaan, membuatnya

54
00:02:45,690 --> 00:02:48,360
‫sangat mudah untuk mendistribusikan data ke

55
00:02:48,360 --> 00:02:50,920
‫beberapa mesin saat aplikasi Anda

56
00:02:50,920 --> 00:02:52,620
‫mendapatkan lebih

57
00:02:52,620 --> 00:02:56,090
‫banyak pengguna dan mulai menghasilkan banyak data.

58
00:02:56,090 --> 00:02:59,710
‫Jadi apa pun yang Anda lakukan, MongoDB akan sangat memudahkan

59
00:02:59,710 --> 00:03:01,110
‫Anda untuk berkembang.

60
00:03:01,110 --> 00:03:04,010
‫Selanjutnya, fitur besar lainnya dari MongoDB adalah

61
00:03:04,010 --> 00:03:06,360
‫fleksibilitasnya yang luar biasa.

62
00:03:06,360 --> 00:03:10,210
‫Jadi tidak perlu mendefinisikan skema data dokumen sebelum

63
00:03:10,210 --> 00:03:12,210
‫mengisinya dengan data, artinya

64
00:03:12,210 --> 00:03:15,460
‫setiap dokumen dapat memiliki jumlah dan jenis

65
00:03:15,460 --> 00:03:17,160
‫field yang berbeda.

66
00:03:17,160 --> 00:03:20,120
‫Dan kami juga dapat mengubah bidang ini setiap saat.

67
00:03:20,120 --> 00:03:22,130
‫Dan semua ini benar-benar sejalan

68
00:03:22,130 --> 00:03:24,460
‫dengan beberapa situasi bisnis dunia nyata, dan

69
00:03:24,460 --> 00:03:26,690
‫karena itu dapat menjadi sangat berguna.

70
00:03:26,690 --> 00:03:31,550
‫MongoDB juga merupakan sistem database yang sangat berkinerja.

71
00:03:31,550 --> 00:03:34,680
‫Berkat fitur seperti model data yang

72
00:03:34,680 --> 00:03:37,645
‫disematkan, pengindeksan, sharding, dokumen fleksibel

73
00:03:37,645 --> 00:03:41,290
‫yang telah kita bicarakan, duplikasi asli, dan

74
00:03:41,290 --> 00:03:43,010
‫banyak lagi.

75
00:03:43,010 --> 00:03:45,850
‫Dan Anda tidak perlu mengetahui semua ini,

76
00:03:45,850 --> 00:03:50,320
‫tentu saja, tetapi sangat menyenangkan mengetahui bahwa MongoDB memiliki kinerja tinggi

77
00:03:50,320 --> 00:03:52,100
‫jika kita membutuhkannya.

78
00:03:52,100 --> 00:03:55,270
‫Terakhir, saya hanya ingin menambahkan bahwa MongoDB

79
00:03:55,270 --> 00:03:57,710
‫adalah database sumber terbuka

80
00:03:57,710 --> 00:04:01,350
‫dan gratis, yang diterbitkan di bawah lisensi SSPL.

81
00:04:01,350 --> 00:04:04,700
‫Jadi secara ringkas, kita dapat mengatakan bahwa MongoDB

82
00:04:04,700 --> 00:04:06,770
‫adalah sistem basis data

83
00:04:06,770 --> 00:04:09,600
‫yang hebat untuk membangun banyak jenis aplikasi

84
00:04:09,600 --> 00:04:11,900
‫web modern, skalabel, dan fleksibel.

85
00:04:11,900 --> 00:04:15,450
‫Dan faktanya, Mongo mungkin adalah database yang paling banyak

86
00:04:15,450 --> 00:04:18,250
‫digunakan tanpa JS, sehingga sangat cocok untuk

87
00:04:18,250 --> 00:04:20,690
‫kita gunakan dalam kursus ini.

88
00:04:20,690 --> 00:04:22,970
‫Oke, sekarang mari kita bicara

89
00:04:22,970 --> 00:04:25,910
‫sedikit lebih dalam tentang dokumen-dokumen ini, dan

90
00:04:25,910 --> 00:04:28,540
‫kembali ke contoh posting blog kita

91
00:04:28,540 --> 00:04:31,330
‫dari awal, ini bisa menjadi representasi yang

92
00:04:31,330 --> 00:04:34,140
‫sangat sederhana dari satu dokumen posting, bukan?

93
00:04:34,140 --> 00:04:36,720
‫Dan sekarang hanya untuk perbandingan, berikut adalah

94
00:04:36,720 --> 00:04:38,930
‫bagaimana data yang sama persis

95
00:04:38,930 --> 00:04:42,250
‫bisa terlihat seperti baris dalam database relasional seperti

96
00:04:42,250 --> 00:04:45,580
‫MySQL, atau bahkan dalam spreadsheet Excel, jika Anda

97
00:04:45,580 --> 00:04:47,640
‫lebih terbiasa dengan itu.

98
00:04:47,640 --> 00:04:49,730
‫Jadi seperti yang saya sebutkan

99
00:04:49,730 --> 00:04:53,190
‫sedikit sebelumnya, MongoDB menggunakan format data yang mirip dengan

100
00:04:53,190 --> 00:04:56,070
‫JSON untuk penyimpanan data yang disebut BSON.

101
00:04:56,070 --> 00:04:58,970
‫Tampilannya pada dasarnya sama dengan JSON,

102
00:04:58,970 --> 00:05:01,650
‫tetapi diketik, artinya semua

103
00:05:01,650 --> 00:05:05,450
‫nilai akan memiliki tipe data seperti string, Boolean,

104
00:05:05,450 --> 00:05:09,050
‫tanggal dan pengajar, objek ganda atau lebih.

105
00:05:09,050 --> 00:05:11,890
‫Kita akan mempelajari semua ini nanti dalam praktik.

106
00:05:11,890 --> 00:05:15,030
‫Jadi apa artinya semua dokumen MongoDB

107
00:05:15,030 --> 00:05:16,700
‫akan benar-benar

108
00:05:16,700 --> 00:05:20,220
‫diketik, yang berbeda dari JSON, oke?

109
00:05:20,220 --> 00:05:23,830
‫Sekarang seperti JSON, dokumen BSON ini juga akan

110
00:05:23,830 --> 00:05:26,570
‫memiliki bidang dan data disimpan dalam

111
00:05:26,570 --> 00:05:28,270
‫pasangan nilai kunci.

112
00:05:28,270 --> 00:05:30,840
‫Di sisi lain, dalam

113
00:05:30,840 --> 00:05:33,730
‫database relasional, setiap bidang disebut kolom.

114
00:05:33,730 --> 00:05:35,400
‫Jadi di sini sekali

115
00:05:35,400 --> 00:05:38,920
‫lagi Anda dapat melihat bagaimana database ini mengatur data

116
00:05:38,920 --> 00:05:42,590
‫dalam struktur tabel sementara data JSON kami jauh lebih fleksibel.

117
00:05:42,590 --> 00:05:44,300
‫Ambil contoh bidang tag,

118
00:05:44,300 --> 00:05:46,170
‫di mana kita sebenarnya memiliki

119
00:05:46,170 --> 00:05:50,470
‫array, jadi pada dasarnya kita memiliki beberapa nilai untuk satu bidang, bukan?

120
00:05:50,470 --> 00:05:54,140
‫Jadi MongoDB, ruang dan DV dalam hal ini.

121
00:05:54,140 --> 00:05:57,040
‫Tetapi dalam database relasional, itu tidak benar-benar diperbolehkan.

122
00:05:57,040 --> 00:06:00,020
‫Kami tidak dapat memiliki banyak nilai dalam satu bidang,

123
00:06:00,020 --> 00:06:03,100
‫jadi kami benar-benar harus menemukan solusi untuk ini yang

124
00:06:03,100 --> 00:06:05,150
‫kemudian dapat melibatkan lebih banyak

125
00:06:05,150 --> 00:06:07,550
‫pekerjaan dan lebih banyak komplikasi secara keseluruhan.

126
00:06:07,550 --> 00:06:10,540
‫Sekarang fitur lain yang sangat penting di

127
00:06:10,540 --> 00:06:13,040
‫MongoDB adalah konsep dokumen yang

128
00:06:13,040 --> 00:06:16,120
‫disematkan, yang, sekali lagi, sesuatu yang tidak

129
00:06:16,120 --> 00:06:18,290
‫ada dalam database relasional.

130
00:06:18,290 --> 00:06:19,970
‫Jadi di kolom komentar

131
00:06:19,970 --> 00:06:23,050
‫kami di sini, kami memiliki array yang berisi tiga objek.

132
00:06:23,050 --> 00:06:24,500
‫Satu untuk

133
00:06:24,500 --> 00:06:26,280
‫setiap dokumen, dan masing-masing

134
00:06:26,280 --> 00:06:28,700
‫sebenarnya bisa menjadi dokumennya sendiri, bukan?

135
00:06:28,700 --> 00:06:31,360
‫Jadi bayangkan saja kita memiliki

136
00:06:31,360 --> 00:06:34,550
‫koleksi komentar yang berisi sekumpulan dokumen komentar.

137
00:06:34,550 --> 00:06:37,670
‫Masing-masing dari mereka sebenarnya bisa terlihat persis seperti

138
00:06:37,670 --> 00:06:40,600
‫ini, jadi dengan seorang penulis dan dengan

139
00:06:40,600 --> 00:06:42,200
‫teks komentar, tetapi

140
00:06:42,200 --> 00:06:45,850
‫alih-alih melakukan itu, kami menyertakan komentar ini langsung ke

141
00:06:45,850 --> 00:06:49,610
‫dokumen posting blog, jadi dengan kata lain, kami menyematkan dokumen

142
00:06:49,610 --> 00:06:52,270
‫komentar langsung ke dalam dokumen pos.

143
00:06:52,270 --> 00:06:55,410
‫Jadi proses penyematan, atau de-normalisasi seperti yang

144
00:06:55,410 --> 00:06:59,070
‫kita juga bisa menyebutnya, pada dasarnya adalah untuk memasukkan,

145
00:06:59,070 --> 00:07:01,930
‫jadi, untuk menyematkan, beberapa data terkait ke

146
00:07:01,930 --> 00:07:04,040
‫dalam satu dokumen tunggal.

147
00:07:04,040 --> 00:07:07,540
‫Dalam contoh ini, komentar terkait dengan postingan,

148
00:07:07,540 --> 00:07:10,880
‫sehingga disertakan dalam dokumen yang sama.

149
00:07:10,880 --> 00:07:13,380
‫Dan ini membuat database lebih berperforma dalam

150
00:07:13,380 --> 00:07:15,760
‫beberapa situasi karena dengan cara ini,

151
00:07:15,760 --> 00:07:17,340
‫akan lebih mudah

152
00:07:17,340 --> 00:07:20,150
‫untuk membaca semua data yang kita butuhkan sekaligus.

153
00:07:20,150 --> 00:07:23,270
‫Dan ini adalah sesuatu yang akan banyak kita bicarakan saat

154
00:07:23,270 --> 00:07:25,320
‫mempelajari pemodelan data, tetapi untuk

155
00:07:25,320 --> 00:07:28,720
‫saat ini, saya harap ini masih masuk akal bagi Anda.

156
00:07:28,720 --> 00:07:31,850
‫Sekarang, kebalikan dari embedding atau de-normalisasi,

157
00:07:31,850 --> 00:07:35,520
‫adalah normalisasi, dan begitulah data selalu dimodelkan

158
00:07:35,520 --> 00:07:37,200
‫dalam database relasional.

159
00:07:37,200 --> 00:07:40,430
‫Jadi dalam hal ini, tidak mungkin untuk menyematkan

160
00:07:40,430 --> 00:07:42,070
‫data, jadi solusinya

161
00:07:42,070 --> 00:07:44,480
‫adalah membuat tabel baru untuk

162
00:07:44,480 --> 00:07:47,320
‫komentar dan kemudian bergabung dengan tabel dengan

163
00:07:47,320 --> 00:07:50,250
‫merujuk ke bidang ID dari tabel komentar.

164
00:07:50,250 --> 00:07:52,590
‫Sekarang kita tidak akan menggunakan database relasional

165
00:07:52,590 --> 00:07:55,460
‫dalam kursus ini, tapi saya yakin masih penting

166
00:07:55,460 --> 00:07:57,510
‫untuk mengetahui perbedaannya jika Anda

167
00:07:57,510 --> 00:07:59,630
‫ingin menjadi pengembang back-end yang baik.

168
00:07:59,630 --> 00:08:01,940
‫Bagaimanapun, dan sekarang hanya untuk

169
00:08:01,940 --> 00:08:04,810
‫menyelesaikan, dua hal lagi tentang dokumen BSON.

170
00:08:04,810 --> 00:08:07,510
‫Pertama, ukuran maksimum untuk setiap dokumen

171
00:08:07,510 --> 00:08:12,120
‫saat ini adalah 16 MB, tetapi ini mungkin meningkat di masa mendatang.

172
00:08:12,120 --> 00:08:16,180
‫Dan kedua, setiap dokumen berisi ID unik, yang

173
00:08:16,180 --> 00:08:19,900
‫bertindak sebagai kunci utama dokumen itu.

174
00:08:19,900 --> 00:08:23,780
‫Ini dibuat secara otomatis dengan tipe data ID objek

175
00:08:23,780 --> 00:08:26,000
‫setiap kali ada dokumen

176
00:08:26,000 --> 00:08:28,605
‫baru, jadi kita tidak perlu mengkhawatirkannya.

177
00:08:28,605 --> 00:08:32,240
‫Baiklah, dan itu seharusnya menjadi gambaran singkat yang cukup

178
00:08:32,240 --> 00:08:33,610
‫untuk kita mulai,

179
00:08:33,610 --> 00:08:37,210
‫dan untuk benar-benar menggunakan MongoDB dari kuliah berikutnya.

180
00:08:37,210 --> 00:08:38,873
‫Jadi, mari kita lanjutkan sekarang.

