1
00:00:03,710 --> 00:00:08,700
Позвольте мне дать вам краткий обзор MongoDB.

2
00:00:08,700 --> 00:00:10,875
Почему MongoDB интересен?

3
00:00:10,875 --> 00:00:13,165
Как это полезно для нашего приложения?

4
00:00:13,165 --> 00:00:16,290
И каковы некоторые из характерных особенностей MongoDB в

5
00:00:16,290 --> 00:00:19,845
отличие от традиционных баз данных SQL?

6
00:00:19,845 --> 00:00:23,190
Таким образом, это не будет целые договоры или базы данных.

7
00:00:23,190 --> 00:00:25,890
Я предполагаю, что у вас достаточно знаний о базах данных.

8
00:00:25,890 --> 00:00:31,050
Так что я бы представил, что MongoDB было бы легко для вас следовать.

9
00:00:31,050 --> 00:00:34,695
Исходя из ваших предыдущих знаний о базах данных,

10
00:00:34,695 --> 00:00:40,235
я предполагаю, что вы уже понимаете, что базы данных используются для хранения структурированных данных,

11
00:00:40,235 --> 00:00:42,515
а также позволяют выполнять

12
00:00:42,515 --> 00:00:46,455
различные операции с данными, включая запрос данных,

13
00:00:46,455 --> 00:00:48,740
вставку записей в базу данных,

14
00:00:48,740 --> 00:00:53,870
обновление существующей записи в базе данных или удаление записи из базы данных.

15
00:00:53,870 --> 00:00:58,795
Типичные операции crud, поддерживаемые в базах данных.

16
00:00:58,795 --> 00:01:02,870
Структурированный язык запросов или базы данных на основе SQL были

17
00:01:02,870 --> 00:01:07,330
очень популярны в течение длительного времени как средство хранения данных.

18
00:01:07,330 --> 00:01:13,760
MySQL является одним из примеров базы данных на основе SQL.

19
00:01:13,760 --> 00:01:16,850
Они были очень эффективными в хранении

20
00:01:16,850 --> 00:01:20,230
данных, а затем удовлетворении многих потребностей приложений.

21
00:01:20,230 --> 00:01:27,650
Действительно, многие веб-сайты уже используют базы данных SQL в качестве бэкэнда для хранения данных

22
00:01:27,650 --> 00:01:30,630
, учитывая, что почему нет баз данных SQL

23
00:01:30,630 --> 00:01:35,610
важно с новыми видами приложений, которые приходят в оперативный режим.

24
00:01:35,610 --> 00:01:37,850
Возрастает спрос на

25
00:01:37,850 --> 00:01:43,170
новые функции, которые не все базы данных на основе SQL могут использоваться.

26
00:01:43,170 --> 00:01:46,400
Таким образом, здесь база данных на основе NoSQL не только

27
00:01:46,400 --> 00:01:51,485
база данных на основе SQL получает много грантов,

28
00:01:51,485 --> 00:01:54,720
одним из примеров этого является MongoDB.

29
00:01:54,720 --> 00:01:58,745
Таким образом, базы данных NoSQL предназначены для

30
00:01:58,745 --> 00:02:03,305
устранения некоторых недостатков баз данных на основе SQL.

31
00:02:03,305 --> 00:02:08,935
Сами базы данных NoSQL можно разделить на четыре различные категории.

32
00:02:08,935 --> 00:02:13,315
У нас есть базы данных на основе документов, такие как MongoDB,

33
00:02:13,315 --> 00:02:17,820
у нас есть более простые базы данных на основе ключевых значений, такие как Redis,

34
00:02:17,820 --> 00:02:24,710
базы данных на основе столбцов, такие как Cassandra, а затем новые базы данных графа, такие как

35
00:02:24,710 --> 00:02:32,210
Neo4J, и действительно есть больше на рынке, чем эти примеры, которые я дал.

36
00:02:32,210 --> 00:02:34,370
Но, конечно, в этом курсе

37
00:02:34,370 --> 00:02:40,050
мы сосредоточимся в первую очередь на базах данных, основанных на документации, в частности MongoDB.

38
00:02:40,050 --> 00:02:44,855
Так что я расскажу больше о MongoDB в остальной части этой лекции.

39
00:02:44,855 --> 00:02:48,095
Базы данных документов, как следует из названия,

40
00:02:48,095 --> 00:02:50,200
построены вокруг документов.

41
00:02:50,200 --> 00:02:56,530
Документ является автономной единицей информации и может быть в различных форматах,

42
00:02:56,530 --> 00:03:03,425
JSON является одним из самых популярных форматов для хранения документов в базе данных документов.

43
00:03:03,425 --> 00:03:07,535
В качестве примера здесь показан документ JSON, и

44
00:03:07,535 --> 00:03:12,215
это будет то, что даровано в типичной базе данных документов.

45
00:03:12,215 --> 00:03:15,730
Сами документы могут быть организованы в коллекции.

46
00:03:15,730 --> 00:03:20,830
Таким образом, коллекция представляет собой группу документов и, в свою очередь,

47
00:03:20,830 --> 00:03:26,205
сама база данных может рассматриваться как набор коллекций.

48
00:03:26,205 --> 00:03:31,970
Таким образом, эти термины, «Коллекции документов» и «База данных» будут возникать

49
00:03:31,970 --> 00:03:39,290
часто, когда мы обсуждаем о базах данных документов и MongoDB в частности.

50
00:03:39,290 --> 00:03:42,910
Почему нам интересны базы данных NoSQL?

51
00:03:42,910 --> 00:03:45,890
В частности, масштабируемость является одной из

52
00:03:45,890 --> 00:03:49,560
причин, почему базы данных NoSQL очень хорошо освещались.

53
00:03:49,560 --> 00:03:52,015
Теперь с точки зрения масштабируемости,

54
00:03:52,015 --> 00:03:53,630
когда мы рассмотрим два требования:

55
00:03:53,630 --> 00:03:56,990
доступность и согласованность баз данных, как правило,

56
00:03:56,990 --> 00:04:02,390
базы данных SQL очень трудно удовлетворить оба требования одновременно.

57
00:04:02,390 --> 00:04:05,239
Таким образом, существует компромисс между доступностью и согласованностью.

58
00:04:05,239 --> 00:04:08,690
Таким образом, здесь базы данных NoSQL были намного

59
00:04:08,690 --> 00:04:12,175
успешнее в удовлетворении обоих требований.

60
00:04:12,175 --> 00:04:14,705
Здесь

61
00:04:14,705 --> 00:04:17,465
также вступает в силу третий аспект, выделенный здесь, допуск к разделению.

62
00:04:17,465 --> 00:04:23,660
Теперь разбиение базы данных SQL, а затем ее распространение не так просто.

63
00:04:23,660 --> 00:04:29,239
В то время как база данных NoSQL гораздо более

64
00:04:29,239 --> 00:04:34,755
поддается разделению, а затем распределяется по нескольким серверам.

65
00:04:34,755 --> 00:04:40,990
Второй аспект, почему базы данных NoSQL были популярны, это простота развертывания.

66
00:04:40,990 --> 00:04:43,165
При использовании базы данных SQL

67
00:04:43,165 --> 00:04:48,200
необходимо

68
00:04:48,200 --> 00:04:53,410
сопоставить записи в базе данных SQL с объектами на родном языке, такими как Java или Javascript и так далее.

69
00:04:53,410 --> 00:04:56,810
Таким образом, существует потребность в объектно-реляционном сопоставлении, и именно

70
00:04:56,810 --> 00:05:00,920
в этом случае промежуточный шлюз должен заполнить это требование.

71
00:05:00,920 --> 00:05:07,950
С базой данных NoSQL, такой как база данных на основе документов, хранящая данные в виде JSON,

72
00:05:07,950 --> 00:05:12,200
сопоставление становится довольно простым, и это одна из причин, почему

73
00:05:12,200 --> 00:05:17,900
базы данных NoSQL были очень популярны в области веб-разработки.

74
00:05:17,900 --> 00:05:20,680
Приходя к MongoDB, в частности,

75
00:05:20,680 --> 00:05:23,820
MongoDB является базой данных документов.

76
00:05:23,820 --> 00:05:27,150
Сам сервер может поддерживать несколько баз данных.

77
00:05:27,150 --> 00:05:31,790
База данных, в частности, представляет собой набор коллекций

78
00:05:31,790 --> 00:05:36,620
и сама коллекция, как мы обсуждали ранее, представляет собой набор документов.

79
00:05:36,620 --> 00:05:41,705
Таким образом, документ становится единицей информации в случае MongoDB.

80
00:05:41,705 --> 00:05:46,825
Документ в MongoDB - это не что иное, как документ JSON.

81
00:05:46,825 --> 00:05:53,470
На самом деле MongoDB хранит документ в более компактном виде, называемом как формат BSON.

82
00:05:53,470 --> 00:05:56,495
Мы поговорим об этом на следующем слайде.

83
00:05:56,495 --> 00:06:00,175
В то время как MongoDB является базой данных на основе документов,

84
00:06:00,175 --> 00:06:04,160
он хранит документы JSON в компактном виде,

85
00:06:04,160 --> 00:06:09,125
называемом как формат BSON или двоичный формат JSON.

86
00:06:09,125 --> 00:06:12,920
Теперь это поддерживает префикс длины для каждого значения

87
00:06:12,920 --> 00:06:16,870
, так что пропуск поля становится намного проще.

88
00:06:16,870 --> 00:06:23,365
Таким образом, как вы видите, MongoDB поддерживает дополнительные функции, чем простая база данных документов.

89
00:06:23,365 --> 00:06:27,835
Также хранится информация о типе значения поля.

90
00:06:27,835 --> 00:06:31,280
Кроме того, в документе JSON

91
00:06:31,280 --> 00:06:35,405
сохраняются дополнительные примитивные типы, которые

92
00:06:35,405 --> 00:06:39,860
полезны при выполнении операций с базой данных.

93
00:06:39,860 --> 00:06:43,190
Такие вещи, как формат даты UTC,

94
00:06:43,190 --> 00:06:48,920
он также поддерживает необработанный двоичный файл, а также использует формат идентификатора объекта

95
00:06:48,920 --> 00:06:54,790
для хранения идентификатора каждого документа в базе данных, если вы хотите.

96
00:06:54,790 --> 00:06:58,745
Давайте поговорим об этом чуть более подробно на следующем слайде.

97
00:06:58,745 --> 00:07:02,330
Давайте поговорим о идентификаторе объекта MongoDB.

98
00:07:02,330 --> 00:07:07,000
Каждый документ в базе данных MongoDB должен иметь поле ID,

99
00:07:07,000 --> 00:07:08,985
поле ID подчеркивания,

100
00:07:08,985 --> 00:07:14,055
которое действует в качестве первичного ключа для документа.

101
00:07:14,055 --> 00:07:17,465
И это поле уникально для каждого документа.

102
00:07:17,465 --> 00:07:20,810
Само поле ID может быть использовано во

103
00:07:20,810 --> 00:07:25,955
многих форматах и один конкретный формат, который MongoDB автоматически

104
00:07:25,955 --> 00:07:30,020
присваивает, если вы не решите использовать собственное поле ID

105
00:07:30,020 --> 00:07:35,350
является идентификатор объекта, который создается по умолчанию MongoDB.

106
00:07:35,350 --> 00:07:37,550
Таким образом, идентификатор объекта сам по себе

107
00:07:37,550 --> 00:07:43,660
является структурированной частью информации, но хранится как идентификатор документа.

108
00:07:43,660 --> 00:07:47,825
Например, поле ID, которое автоматически

109
00:07:47,825 --> 00:07:52,390
назначается Mongo в случае, если вы не укажете поле ID,

110
00:07:52,390 --> 00:07:55,960
содержит идентификатор объекта в виде длинной строки.

111
00:07:55,960 --> 00:08:00,605
Теперь эта строка имеет определенный формат, который

112
00:08:00,605 --> 00:08:06,530
позволяет ей хранить ряд фрагментов информации в идентификаторе объекта.

113
00:08:06,530 --> 00:08:11,975
Давайте посмотрим на структуру самого идентификатора объекта на следующем слайде.

114
00:08:11,975 --> 00:08:16,325
Как я уже упоминал, само поле ID объекта

115
00:08:16,325 --> 00:08:22,635
является 12-байтовым полем, которое хранит информацию в определенном формате.

116
00:08:22,635 --> 00:08:26,445
Первые четыре байта включают временную

117
00:08:26,445 --> 00:08:31,760
метку, типичную временную метку Unix в разрешении секунды.

118
00:08:31,760 --> 00:08:34,340
Так что это сказано в первых четырех байтах.

119
00:08:34,340 --> 00:08:37,580
Затем следующие три байта к идентификатору машины,

120
00:08:37,580 --> 00:08:40,490
компьютер, на котором работает сервер Mongo,

121
00:08:40,490 --> 00:08:43,910
и следующие два байта - идентификатор процесса,

122
00:08:43,910 --> 00:08:47,000
конкретный процесс Mongo, который создал

123
00:08:47,000 --> 00:08:50,674
этот документ, а затем последнее поле является приращением.

124
00:08:50,674 --> 00:08:52,490
Теперь, как вы понимаете,

125
00:08:52,490 --> 00:08:56,390
само поле метки времени находится на разрешении секунды.

126
00:08:56,390 --> 00:09:00,110
Поэтому, если у вас есть несколько документов, которые хранятся в течение одной секунды,

127
00:09:00,110 --> 00:09:03,735
поле приращения будет различать документы.

128
00:09:03,735 --> 00:09:06,500
Они инкрементное поле является самоувеличивающимся полем.

129
00:09:06,500 --> 00:09:11,750
Таким образом, каждый новый документ, созданный в течение секунды, получит новое значение приращения.

130
00:09:11,750 --> 00:09:14,150
Таким образом, в сочетании с этими двумя,

131
00:09:14,150 --> 00:09:16,655
вы можете легко различать

132
00:09:16,655 --> 00:09:21,550
различные документы, которые хранятся в вашей базе данных документов.

133
00:09:21,550 --> 00:09:28,500
Таким образом, это позволяет четко давать уникальный идентификатор каждому документу.

134
00:09:28,500 --> 00:09:30,960
Мало того, что, учитывая идентификатор,

135
00:09:30,960 --> 00:09:34,050
вы можете легко получить информацию из этого идентификатора.

136
00:09:34,050 --> 00:09:37,460
Так, например, вы можете получить ObjectID, а затем вызвать

137
00:09:37,460 --> 00:09:40,880
метод getTimestamp идентификатора объекта, и

138
00:09:40,880 --> 00:09:44,655
это вернет временную метку в формате даты ISO.

139
00:09:44,655 --> 00:09:49,595
Таким образом, вы сможете определить, когда этот документ был создан.

140
00:09:49,595 --> 00:09:52,750
С этим быстрым пониманием MongoDB,

141
00:09:52,750 --> 00:09:58,700
давайте перейдем к упражнению, где мы сначала установим MongoDB на нашем компьютере,

142
00:09:58,700 --> 00:10:04,970
а затем взаимодействуем с базой данных MongoDB, используя

143
00:10:04,970 --> 00:10:09,365
пульсацию Mongo, чтение оценки цикла печати, который Mongo поддерживает.

144
00:10:09,365 --> 00:10:12,695
Теперь, после этого, мы рассмотрим, как мы можем получить доступ к

145
00:10:12,695 --> 00:10:19,830
серверу Mongo из нашего приложения узла в следующем уроке.