1
00:00:03,710 --> 00:00:08,700
Hãy để tôi cung cấp cho bạn một cái nhìn tổng quan nhanh về MongoDB.

2
00:00:08,700 --> 00:00:10,875
Tại sao MongoDB lại thú vị?

3
00:00:10,875 --> 00:00:13,165
Làm thế nào là nó hữu ích cho ứng dụng của chúng tôi?

4
00:00:13,165 --> 00:00:16,290
Và một số tính năng nổi bật của MongoDB

5
00:00:16,290 --> 00:00:19,845
trái ngược với cơ sở dữ liệu SQL truyền thống là gì?

6
00:00:19,845 --> 00:00:23,190
Vì vậy, đây sẽ không phải là một toàn bộ hiệp ước hoặc cơ sở dữ liệu.

7
00:00:23,190 --> 00:00:25,890
Tôi cho rằng bạn có đủ kiến thức về cơ sở dữ liệu.

8
00:00:25,890 --> 00:00:31,050
Vì vậy, những gì tôi sẽ giới thiệu những gì MongoDB sẽ được dễ dàng cho bạn để làm theo.

9
00:00:31,050 --> 00:00:34,695
Từ kiến thức trước đây của bạn về cơ sở dữ liệu,

10
00:00:34,695 --> 00:00:40,235
tôi cho rằng bạn đã hiểu rằng cơ sở dữ liệu được sử dụng để lưu trữ dữ liệu có cấu trúc

11
00:00:40,235 --> 00:00:42,515
và cũng cho phép bạn thực hiện

12
00:00:42,515 --> 00:00:46,455
các thao tác khác nhau của dữ liệu bao gồm truy vấn dữ liệu,

13
00:00:46,455 --> 00:00:48,740
chèn bản ghi vào cơ sở dữ liệu,

14
00:00:48,740 --> 00:00:53,870
cập nhật một bản ghi hiện có trong cơ sở dữ liệu hoặc xóa một bản ghi khỏi cơ sở dữ liệu.

15
00:00:53,870 --> 00:00:58,795
Các hoạt động thô điển hình được hỗ trợ trên cơ sở dữ liệu.

16
00:00:58,795 --> 00:01:02,870
Ngôn ngữ truy vấn có cấu trúc hoặc cơ sở dữ liệu dựa trên SQL đã

17
00:01:02,870 --> 00:01:07,330
rất phổ biến trong một thời gian dài như một phương tiện lưu trữ dữ liệu.

18
00:01:07,330 --> 00:01:13,760
MySQL là một ví dụ về cơ sở dữ liệu dựa trên SQL.

19
00:01:13,760 --> 00:01:16,850
Chúng đã rất hiệu quả trong việc lưu trữ

20
00:01:16,850 --> 00:01:20,230
dữ liệu và sau đó giải quyết nhiều nhu cầu của các ứng dụng.

21
00:01:20,230 --> 00:01:27,650
Thật vậy, nhiều trang web đã sử dụng cơ sở dữ liệu SQL làm phụ trợ để lưu trữ dữ liệu cho

22
00:01:27,650 --> 00:01:30,630
rằng tại sao không có cơ sở dữ liệu SQL

23
00:01:30,630 --> 00:01:35,610
quan trọng với các loại ứng dụng mới đang đến trực tuyến.

24
00:01:35,610 --> 00:01:37,850
Có một nhu cầu ngày càng tăng cho các

25
00:01:37,850 --> 00:01:43,170
tính năng mới không phải tất cả trong số đó cơ sở dữ liệu dựa trên SQL có thể giải quyết.

26
00:01:43,170 --> 00:01:46,400
Vì vậy, đây là nơi cơ sở dữ liệu dựa trên NoSQL không chỉ

27
00:01:46,400 --> 00:01:51,485
cơ sở dữ liệu dựa trên SQL đang đạt được rất nhiều cấp,

28
00:01:51,485 --> 00:01:54,720
MongoDB là một ví dụ về điều đó.

29
00:01:54,720 --> 00:01:58,745
Vì vậy, các cơ sở dữ liệu NoSQL được thiết kế để

30
00:01:58,745 --> 00:02:03,305
giải quyết một số thiếu sót của cơ sở dữ liệu dựa trên SQL.

31
00:02:03,305 --> 00:02:08,935
Bản thân cơ sở dữ liệu NoSQL có thể được phân thành bốn loại khác nhau.

32
00:02:08,935 --> 00:02:13,315
Chúng tôi có cơ sở dữ liệu dựa trên tài liệu như MongoDB,

33
00:02:13,315 --> 00:02:17,820
chúng tôi có cơ sở dữ liệu dựa trên giá trị quan trọng đơn giản hơn như Redis,

34
00:02:17,820 --> 00:02:24,710
cơ sở dữ liệu dựa trên cột gia đình như Cassandra và sau đó các cơ sở dữ liệu đồ thị mới hơn như

35
00:02:24,710 --> 00:02:32,210
Neo4J và thực sự có nhiều hơn bây giờ trên thị trường hơn những ví dụ mà tôi đã đưa ra.

36
00:02:32,210 --> 00:02:34,370
Nhưng tất nhiên trong khóa học này,

37
00:02:34,370 --> 00:02:40,050
chúng tôi sẽ tập trung chủ yếu vào cơ sở dữ liệu dựa trên tài liệu, cụ thể là MongoDB.

38
00:02:40,050 --> 00:02:44,855
Vì vậy, tôi sẽ xem xét thêm về MongoDB trong phần còn lại của bài giảng này.

39
00:02:44,855 --> 00:02:48,095
Cơ sở dữ liệu tài liệu, như tên của nó,

40
00:02:48,095 --> 00:02:50,200
được xây dựng xung quanh tài liệu.

41
00:02:50,200 --> 00:02:56,530
Tài liệu là một đơn vị thông tin khép kín và có thể ở nhiều định dạng khác nhau,

42
00:02:56,530 --> 00:03:03,425
JSON là một trong những định dạng phổ biến nhất để lưu trữ tài liệu trong cơ sở dữ liệu tài liệu.

43
00:03:03,425 --> 00:03:07,535
Ví dụ, một tài liệu JSON được hiển thị ở đây và

44
00:03:07,535 --> 00:03:12,215
đây sẽ là một cái gì đó được ban cho trong một cơ sở dữ liệu tài liệu điển hình.

45
00:03:12,215 --> 00:03:15,730
Bản thân tài liệu có thể được tổ chức thành các bộ sưu tập.

46
00:03:15,730 --> 00:03:20,830
Vì vậy, một bộ sưu tập là một nhóm các tài liệu và lần lượt,

47
00:03:20,830 --> 00:03:26,205
cơ sở dữ liệu chính nó có thể được coi là một tập hợp các bộ sưu tập.

48
00:03:26,205 --> 00:03:31,970
Vì vậy, các thuật ngữ này, “Bộ sưu tập tài liệu” và “Cơ sở dữ liệu” sẽ xảy ra

49
00:03:31,970 --> 00:03:39,290
thường xuyên khi chúng ta thảo luận về cơ sở dữ liệu tài liệu và MongoDB nói riêng.

50
00:03:39,290 --> 00:03:42,910
Tại sao cơ sở dữ liệu NoSQL lại quan tâm đến chúng tôi?

51
00:03:42,910 --> 00:03:45,890
Đặc biệt, khả năng mở rộng là một trong

52
00:03:45,890 --> 00:03:49,560
những lý do tại sao cơ sở dữ liệu NoSQL đã tỏa sáng rất tốt.

53
00:03:49,560 --> 00:03:52,015
Bây giờ về khả năng mở rộng,

54
00:03:52,015 --> 00:03:53,630
khi chúng ta nhìn vào hai yêu cầu; tính

55
00:03:53,630 --> 00:03:56,990
khả dụng và tính nhất quán của cơ sở dữ liệu, thông thường,

56
00:03:56,990 --> 00:04:02,390
cơ sở dữ liệu SQL thấy rất khó để đáp ứng cả hai yêu cầu đồng thời.

57
00:04:02,390 --> 00:04:05,239
Vì vậy, có một sự cân bằng giữa tính sẵn sàng và tính nhất quán.

58
00:04:05,239 --> 00:04:08,690
Vì vậy, đây là nơi cơ sở dữ liệu NoSQL đã thành

59
00:04:08,690 --> 00:04:12,175
công hơn rất nhiều trong việc đáp ứng cả hai yêu cầu.

60
00:04:12,175 --> 00:04:14,705
Đây là nơi mà khía cạnh thứ ba được đánh dấu ở đây,

61
00:04:14,705 --> 00:04:17,465
dung sai phân vùng, cũng có hiệu lực.

62
00:04:17,465 --> 00:04:23,660
Bây giờ phân vùng một cơ sở dữ liệu SQL và sau đó phân phối nó không phải là đơn giản.

63
00:04:23,660 --> 00:04:29,239
Trong khi đó, một cơ sở dữ liệu NoSQL có nhiều

64
00:04:29,239 --> 00:04:34,755
khả năng hơn để được chia nhỏ và sau đó phân phối trên nhiều máy chủ.

65
00:04:34,755 --> 00:04:40,990
Khía cạnh thứ hai của lý do tại sao cơ sở dữ liệu NoSQL đã được phổ biến là dễ triển khai.

66
00:04:40,990 --> 00:04:43,165
Khi bạn sử dụng một cơ sở dữ liệu SQL,

67
00:04:43,165 --> 00:04:48,200
cần phải kết hợp các bản ghi trong cơ sở dữ liệu SQL của bạn trở

68
00:04:48,200 --> 00:04:53,410
lại các đối tượng trong ngôn ngữ mẹ đẻ của bạn như Java hoặc Javascript và vân vân.

69
00:04:53,410 --> 00:04:56,810
Vì vậy cần phải lập bản đồ quan hệ đối tượng và đây là

70
00:04:56,810 --> 00:05:00,920
nơi mà một cổng trung gian cần phải điền vào yêu cầu này.

71
00:05:00,920 --> 00:05:07,950
Với một cơ sở dữ liệu NoSQL giống như một cơ sở dữ liệu dựa trên tài liệu lưu trữ dữ liệu dưới dạng JSON,

72
00:05:07,950 --> 00:05:12,200
việc ánh xạ trở nên khá thẳng về phía trước và đó là một trong những lý do tại sao

73
00:05:12,200 --> 00:05:17,900
cơ sở dữ liệu NoSQL đã rất phổ biến trong khu vực phát triển web.

74
00:05:17,900 --> 00:05:20,680
Đến với MongoDB nói riêng,

75
00:05:20,680 --> 00:05:23,820
MongoDB là một cơ sở dữ liệu tài liệu.

76
00:05:23,820 --> 00:05:27,150
Bản thân máy chủ có thể hỗ trợ nhiều cơ sở dữ liệu.

77
00:05:27,150 --> 00:05:31,790
Một cơ sở dữ liệu nói riêng là một tập hợp các bộ sưu tập

78
00:05:31,790 --> 00:05:36,620
và bộ sưu tập chính nó như chúng ta đã thảo luận trước đó là một tập hợp các tài liệu.

79
00:05:36,620 --> 00:05:41,705
Vì vậy, tài liệu trở thành đơn vị thông tin trong trường hợp của MongoDB.

80
00:05:41,705 --> 00:05:46,825
Các tài liệu trong MongoDB không là gì ngoài một tài liệu JSON.

81
00:05:46,825 --> 00:05:53,470
Trong thực tế, MongoDB lưu trữ tài liệu dưới dạng nhỏ gọn hơn được gọi là định dạng BSON.

82
00:05:53,470 --> 00:05:56,495
Chúng ta sẽ nói về điều đó trong slide tiếp theo.

83
00:05:56,495 --> 00:06:00,175
Trong khi MongoDB là một cơ sở dữ liệu dựa trên tài liệu,

84
00:06:00,175 --> 00:06:04,160
nó lưu trữ các tài liệu JSON dưới dạng nhỏ gọn

85
00:06:04,160 --> 00:06:09,125
được gọi là định dạng BSON hoặc định dạng JSON nhị phân.

86
00:06:09,125 --> 00:06:12,920
Bây giờ điều này hỗ trợ tiền tố độ dài trên mỗi giá trị để

87
00:06:12,920 --> 00:06:16,870
bỏ qua một trường trở nên dễ dàng hơn nhiều.

88
00:06:16,870 --> 00:06:23,365
Như bạn thấy, MongoDB hỗ trợ các tính năng bổ sung hơn là một cơ sở dữ liệu tài liệu đơn giản.

89
00:06:23,365 --> 00:06:27,835
Thông tin về loại giá trị trường cũng được lưu trữ.

90
00:06:27,835 --> 00:06:31,280
Và ngoài ra, trong tài liệu JSON, các

91
00:06:31,280 --> 00:06:35,405
loại nguyên thủy bổ sung được lưu trữ hữu ích

92
00:06:35,405 --> 00:06:39,860
khi bạn đang thực hiện các thao tác trên cơ sở dữ liệu.

93
00:06:39,860 --> 00:06:43,190
Những thứ như định dạng ngày UTC,

94
00:06:43,190 --> 00:06:48,920
nó cũng hỗ trợ nhị phân thô và cũng sử dụng định dạng ID đối tượng

95
00:06:48,920 --> 00:06:54,790
để lưu trữ ID của từng tài liệu trong cơ sở dữ liệu nếu bạn chọn.

96
00:06:54,790 --> 00:06:58,745
Hãy nói về điều đó trong một chút chi tiết hơn trong slide tiếp theo.

97
00:06:58,745 --> 00:07:02,330
Hãy nói về ID đối tượng MongoDB.

98
00:07:02,330 --> 00:07:07,000
Mỗi tài liệu trong cơ sở dữ liệu MongoDB phải có

99
00:07:07,000 --> 00:07:08,985
một trường ID, một trường ID gạch dưới

100
00:07:08,985 --> 00:07:14,055
, hoạt động như khóa chính cho tài liệu.

101
00:07:14,055 --> 00:07:17,465
Và trường này là duy nhất cho mỗi tài liệu.

102
00:07:17,465 --> 00:07:20,810
Trường ID chính nó có thể được sử dụng trong

103
00:07:20,810 --> 00:07:25,955
nhiều định dạng và một định dạng cụ thể mà MongoDB tự động

104
00:07:25,955 --> 00:07:30,020
gán trong trường hợp bạn không chọn sử dụng trường ID của riêng bạn

105
00:07:30,020 --> 00:07:35,350
là ID đối tượng được tạo ra theo mặc định bởi MongoDB.

106
00:07:35,350 --> 00:07:37,550
Vì vậy, đối tượng ID chính nó là

107
00:07:37,550 --> 00:07:43,660
một phần có cấu trúc của thông tin nhưng được lưu trữ dưới dạng ID của tài liệu.

108
00:07:43,660 --> 00:07:47,825
Ví dụ: trường ID được tự động

109
00:07:47,825 --> 00:07:52,390
gán bởi Mongo trong trường hợp bạn không chỉ định một trường ID,

110
00:07:52,390 --> 00:07:55,960
chứa ID đối tượng dưới dạng một chuỗi dài.

111
00:07:55,960 --> 00:08:00,605
Bây giờ chuỗi này có một định dạng cụ thể

112
00:08:00,605 --> 00:08:06,530
cho phép nó lưu trữ một số mẩu thông tin trong ID đối tượng.

113
00:08:06,530 --> 00:08:11,975
Hãy nhìn vào cấu trúc của đối tượng ID chính nó trong trang chiếu tiếp theo.

114
00:08:11,975 --> 00:08:16,325
Như tôi đã đề cập, trường ID đối tượng chính nó là

115
00:08:16,325 --> 00:08:22,635
một trường 12 byte mà lưu trữ thông tin trong một định dạng cụ thể.

116
00:08:22,635 --> 00:08:26,445
Bốn byte đầu tiên bao gồm một dấu thời gian, dấu

117
00:08:26,445 --> 00:08:31,760
thời gian Unix điển hình ở độ phân giải của một giây.

118
00:08:31,760 --> 00:08:34,340
Vì vậy, điều này được nói trong bốn byte đầu tiên.

119
00:08:34,340 --> 00:08:37,580
Sau đó, ba byte tiếp theo đối với ID máy,

120
00:08:37,580 --> 00:08:40,490
máy mà trên đó máy chủ Mongo đang chạy

121
00:08:40,490 --> 00:08:43,910
và hai byte tiếp theo là ID quá trình, quá

122
00:08:43,910 --> 00:08:47,000
trình Mongo cụ thể đã tạo ra

123
00:08:47,000 --> 00:08:50,674
tài liệu này và sau đó trường cuối cùng là một gia tăng.

124
00:08:50,674 --> 00:08:52,490
Bây giờ như bạn đã hiểu,

125
00:08:52,490 --> 00:08:56,390
trường dấu thời gian chính nó là ở độ phân giải của một giây.

126
00:08:56,390 --> 00:09:00,110
Vì vậy, nếu bạn có nhiều tài liệu được lưu trữ trong cùng một giây,

127
00:09:00,110 --> 00:09:03,735
sau đó trường tăng sẽ phân biệt giữa các tài liệu.

128
00:09:03,735 --> 00:09:06,500
Họ tăng trường là một trường tự tăng.

129
00:09:06,500 --> 00:09:11,750
Vì vậy, mỗi tài liệu mới được tạo ra trong vòng một giây sẽ nhận được một giá trị gia tăng mới.

130
00:09:11,750 --> 00:09:14,150
Vì vậy, kết hợp cùng với hai,

131
00:09:14,150 --> 00:09:16,655
bạn có thể dễ dàng phân biệt giữa các

132
00:09:16,655 --> 00:09:21,550
tài liệu khác nhau được lưu trữ trong cơ sở dữ liệu tài liệu của bạn.

133
00:09:21,550 --> 00:09:28,500
Vì vậy, điều này cho phép bạn rõ ràng cung cấp một ID duy nhất cho mỗi tài liệu.

134
00:09:28,500 --> 00:09:30,960
Không chỉ vậy, với một ID,

135
00:09:30,960 --> 00:09:34,050
bạn có thể dễ dàng truy xuất thông tin từ ID này.

136
00:09:34,050 --> 00:09:37,460
Vì vậy, ví dụ, bạn có thể có được giữ của ObjectID và sau đó gọi

137
00:09:37,460 --> 00:09:40,880
phương pháp GetTimestamp của đối tượng ID và

138
00:09:40,880 --> 00:09:44,655
điều này sẽ trả về dấu thời gian trong định dạng ngày ISO.

139
00:09:44,655 --> 00:09:49,595
Vì vậy, điều đó sẽ cho phép bạn xác định khi nào tài liệu này đã được tạo ra.

140
00:09:49,595 --> 00:09:52,750
Với sự hiểu biết nhanh chóng này về MongoDB, chúng ta

141
00:09:52,750 --> 00:09:58,700
hãy tiến hành bài tập nơi chúng ta sẽ cài đặt MongoDB đầu tiên trên máy tính của chúng tôi

142
00:09:58,700 --> 00:10:04,970
và sau đó tương tác với cơ sở dữ liệu MongoDB bằng cách sử dụng gợn sóng Mongo,

143
00:10:04,970 --> 00:10:09,365
đọc đánh giá vòng lặp in mà Mongo hỗ trợ.

144
00:10:09,365 --> 00:10:12,695
Bây giờ sau đó, chúng ta sẽ xem xét cách chúng ta có thể truy cập

145
00:10:12,695 --> 00:10:19,830
máy chủ Mongo từ bên trong ứng dụng nút của chúng tôi trong bài học tiếp theo.