1
00:00:03,710 --> 00:00:08,700
Deixe-me dar-lhe uma rápida visão geral do MongoDB.

2
00:00:08,700 --> 00:00:10,875
Por que MongoDB é interessante?

3
00:00:10,875 --> 00:00:13,165
Como é útil para a nossa aplicação?

4
00:00:13,165 --> 00:00:16,290
E quais são algumas das características salientes do MongoDB em

5
00:00:16,290 --> 00:00:19,845
contraste com os bancos de dados SQL tradicionais?

6
00:00:19,845 --> 00:00:23,190
Portanto, este não será um tratado inteiro ou uma base de dados.

7
00:00:23,190 --> 00:00:25,890
Presumo que tenha conhecimento suficiente de bases de dados.

8
00:00:25,890 --> 00:00:31,050
Então, o que eu apresentaria o MongoDB seria fácil para você seguir.

9
00:00:31,050 --> 00:00:34,695
A partir de seu conhecimento prévio de bancos de dados,

10
00:00:34,695 --> 00:00:40,235
presumo que você já entende que os bancos de dados são usados para armazenar dados estruturados

11
00:00:40,235 --> 00:00:42,515
e também permitem que você execute

12
00:00:42,515 --> 00:00:46,455
várias operações dos dados, incluindo consulta dos dados,

13
00:00:46,455 --> 00:00:48,740
inserção de registros no banco de dados,

14
00:00:48,740 --> 00:00:53,870
atualização de um registro existente no banco de dados ou excluindo um registro do banco de dados.

15
00:00:53,870 --> 00:00:58,795
As operações crud típicas que são suportadas em bancos de dados.

16
00:00:58,795 --> 00:01:02,870
Structured Query Language ou bancos de dados baseados em SQL têm sido

17
00:01:02,870 --> 00:01:07,330
muito populares por um longo tempo como um meio de armazenar dados.

18
00:01:07,330 --> 00:01:13,760
O MySQL é um exemplo de banco de dados baseado em SQL.

19
00:01:13,760 --> 00:01:16,850
Eles têm sido muito eficazes no armazenamento de

20
00:01:16,850 --> 00:01:20,230
dados e, em seguida, atender a muitas das necessidades dos aplicativos.

21
00:01:20,230 --> 00:01:27,650
Na verdade, muitos sites já usam bancos de dados SQL como o backend para armazenar dados dado

22
00:01:27,650 --> 00:01:30,630
que por isso não é

23
00:01:30,630 --> 00:01:35,610
importante bancos de dados SQL com novos tipos de aplicativos que estão ficando on-line.

24
00:01:35,610 --> 00:01:37,850
Há uma demanda crescente por

25
00:01:37,850 --> 00:01:43,170
novos recursos que nem todos os bancos de dados baseados em SQL podem atender.

26
00:01:43,170 --> 00:01:46,400
Então, este é o lugar onde o banco de dados baseado em NoSQL não

27
00:01:46,400 --> 00:01:51,485
são apenas banco de dados baseado em SQL estão ganhando um monte de concessão,

28
00:01:51,485 --> 00:01:54,720
MongoDB sendo um exemplo disso.

29
00:01:54,720 --> 00:01:58,745
Assim, os bancos de dados NoSQL são projetados para

30
00:01:58,745 --> 00:02:03,305
resolver algumas das deficiências de bancos de dados baseados em SQL.

31
00:02:03,305 --> 00:02:08,935
Os próprios bancos de dados NoSQL podem ser classificados em quatro categorias diferentes.

32
00:02:08,935 --> 00:02:13,315
Temos bancos de dados baseados em documentos como MongoDB,

33
00:02:13,315 --> 00:02:17,820
temos os bancos de dados baseados em valor chave mais simples como Redis, bancos de dados

34
00:02:17,820 --> 00:02:24,710
baseados em família de colunas como Cassandra e, em seguida, os bancos de dados gráficos mais recentes como

35
00:02:24,710 --> 00:02:32,210
Neo4J e, na verdade, há mais agora no mercado do que esses exemplos que eu dei.

36
00:02:32,210 --> 00:02:34,370
Mas, claro, neste curso,

37
00:02:34,370 --> 00:02:40,050
estaremos nos concentrando principalmente em bancos de dados baseados em documentos, MongoDB em particular.

38
00:02:40,050 --> 00:02:44,855
Então eu vou rever mais sobre MongoDB no resto desta palestra. Os

39
00:02:44,855 --> 00:02:48,095
bancos de dados de documentos, como o nome indica,

40
00:02:48,095 --> 00:02:50,200
são construídos em torno de documentos.

41
00:02:50,200 --> 00:02:56,530
Um documento é uma unidade independente de informação e pode estar em muitos formatos diferentes,

42
00:02:56,530 --> 00:03:03,425
sendo JSON um dos formatos mais populares para armazenar documentos em um banco de dados de documentos.

43
00:03:03,425 --> 00:03:07,535
Como exemplo, um documento JSON é mostrado aqui e

44
00:03:07,535 --> 00:03:12,215
isso seria algo que é concedido em um banco de dados de documentos típico.

45
00:03:12,215 --> 00:03:15,730
Os próprios documentos podem ser organizados em coleções.

46
00:03:15,730 --> 00:03:20,830
Assim, uma coleção é um grupo de documentos e, por sua vez,

47
00:03:20,830 --> 00:03:26,205
o próprio banco de dados pode ser considerado como um conjunto de coleções.

48
00:03:26,205 --> 00:03:31,970
Portanto, estes termos, “Documentos coleções” e “O banco de dados” ocorrerão

49
00:03:31,970 --> 00:03:39,290
frequentemente quando discutimos sobre bancos de dados de documentos e MongoDB em particular.

50
00:03:39,290 --> 00:03:42,910
Por que os bancos de dados NoSQL são de nosso interesse?

51
00:03:42,910 --> 00:03:45,890
Em particular, a escalabilidade é uma das

52
00:03:45,890 --> 00:03:49,560
razões pelas quais os bancos de dados NoSQL brilharam muito bem.

53
00:03:49,560 --> 00:03:52,015
Agora, em termos de escalabilidade,

54
00:03:52,015 --> 00:03:53,630
quando olhamos para os dois requisitos;

55
00:03:53,630 --> 00:03:56,990
disponibilidade e consistência dos bancos de dados, normalmente, os

56
00:03:56,990 --> 00:04:02,390
bancos de dados SQL acham muito difícil atender aos dois requisitos simultaneamente.

57
00:04:02,390 --> 00:04:05,239
Portanto, há uma troca entre disponibilidade e consistência.

58
00:04:05,239 --> 00:04:08,690
Então é aqui que os bancos de dados NoSQL têm sido muito

59
00:04:08,690 --> 00:04:12,175
mais bem sucedidos em atender aos dois requisitos.

60
00:04:12,175 --> 00:04:14,705
É aqui que o terceiro aspecto destacado aqui, a

61
00:04:14,705 --> 00:04:17,465
tolerância à partição, também entra em vigor.

62
00:04:17,465 --> 00:04:23,660
Agora particionar um banco de dados SQL e, em seguida, distribuí-lo não é tão simples.

63
00:04:23,660 --> 00:04:29,239
Considerando que um banco de dados NoSQL é muito mais passível de

64
00:04:29,239 --> 00:04:34,755
ser subdividido e, em seguida, distribuído entre vários servidores.

65
00:04:34,755 --> 00:04:40,990
O segundo aspecto de porque os bancos de dados NoSQL têm sido populares é a facilidade de implantação.

66
00:04:40,990 --> 00:04:43,165
Quando você usa um banco de dados SQL,

67
00:04:43,165 --> 00:04:48,200
há uma necessidade de corresponder os registros em seu banco de dados SQL de volta

68
00:04:48,200 --> 00:04:53,410
a objetos em sua linguagem nativa, como Java ou Javascript e assim por diante.

69
00:04:53,410 --> 00:04:56,810
Portanto, há uma necessidade de mapeamento relacional de objeto e é aqui

70
00:04:56,810 --> 00:05:00,920
que um gateway intermediário precisa preencher esse requisito.

71
00:05:00,920 --> 00:05:07,950
Com um banco de dados NoSQL como um banco de dados baseado em documentos armazenando dados na forma de JSON,

72
00:05:07,950 --> 00:05:12,200
o mapeamento torna-se bastante direto e essa é uma das razões pelas quais os

73
00:05:12,200 --> 00:05:17,900
bancos de dados NoSQL têm sido muito populares na área de desenvolvimento web.

74
00:05:17,900 --> 00:05:20,680
Vindo para MongoDB em particular,

75
00:05:20,680 --> 00:05:23,820
MongoDB é um banco de dados de documentos.

76
00:05:23,820 --> 00:05:27,150
O próprio servidor pode suportar vários bancos de dados.

77
00:05:27,150 --> 00:05:31,790
Um banco de dados em particular é um conjunto de coleções

78
00:05:31,790 --> 00:05:36,620
e a própria coleção como discutimos anteriormente é um conjunto de documentos.

79
00:05:36,620 --> 00:05:41,705
Assim, o documento torna-se a unidade de informação no caso de MongoDB.

80
00:05:41,705 --> 00:05:46,825
O documento no MongoDB não é nada além de um documento JSON.

81
00:05:46,825 --> 00:05:53,470
Na verdade, MongoDB armazena o documento em uma forma mais compacta chamada como o formato BSON.

82
00:05:53,470 --> 00:05:56,495
Falaremos sobre isso no próximo slide.

83
00:05:56,495 --> 00:06:00,175
Enquanto MongoDB é um banco de dados baseado em documentos,

84
00:06:00,175 --> 00:06:04,160
ele armazena os documentos JSON em um formato compacto

85
00:06:04,160 --> 00:06:09,125
chamado como o formato BSON ou o formato JSON binário.

86
00:06:09,125 --> 00:06:12,920
Agora isso suporta prefixo de comprimento em cada valor para

87
00:06:12,920 --> 00:06:16,870
que pular sobre um campo se torne muito mais fácil.

88
00:06:16,870 --> 00:06:23,365
Então, como você vê, MongoDB suporta recursos adicionais do que um banco de dados de documentos simples.

89
00:06:23,365 --> 00:06:27,835
As informações sobre o tipo de um valor de campo também são armazenadas.

90
00:06:27,835 --> 00:06:31,280
Além disso, dentro do documento JSON,

91
00:06:31,280 --> 00:06:35,405
tipos primitivos adicionais são armazenados que são úteis

92
00:06:35,405 --> 00:06:39,860
quando você está executando operações no banco de dados.

93
00:06:39,860 --> 00:06:43,190
Coisas como o formato de data UTC,

94
00:06:43,190 --> 00:06:48,920
ele também suporta binário bruto e também usa um formato de ID de objeto

95
00:06:48,920 --> 00:06:54,790
para armazenar o ID de cada documento no banco de dados, se você escolher.

96
00:06:54,790 --> 00:06:58,745
Vamos falar sobre isso com um pouco mais de detalhes no próximo slide.

97
00:06:58,745 --> 00:07:02,330
Vamos falar sobre o ID do objeto MongoDB.

98
00:07:02,330 --> 00:07:07,000
Cada documento no banco de dados MongoDB deve ter um campo ID,

99
00:07:07,000 --> 00:07:08,985
um campo ID sublinhado,

100
00:07:08,985 --> 00:07:14,055
que atua como a chave primária para o documento.

101
00:07:14,055 --> 00:07:17,465
E esse campo é exclusivo para cada documento.

102
00:07:17,465 --> 00:07:20,810
O campo ID em si pode ser usado em

103
00:07:20,810 --> 00:07:25,955
muitos formatos e um formato particular que MongoDB

104
00:07:25,955 --> 00:07:30,020
atribui automaticamente no caso de você não optar por usar seu próprio campo ID

105
00:07:30,020 --> 00:07:35,350
é o ID do objeto que é criado por padrão pelo MongoDB.

106
00:07:35,350 --> 00:07:37,550
Assim, o ID do objeto em si é

107
00:07:37,550 --> 00:07:43,660
um pedaço estruturado de informação, mas é armazenado como o ID do documento.

108
00:07:43,660 --> 00:07:47,825
Como exemplo, o campo ID que é

109
00:07:47,825 --> 00:07:52,390
atribuído automaticamente pelo Mongo no caso de você não especificar um campo ID,

110
00:07:52,390 --> 00:07:55,960
contém o ID do objeto na forma de uma string longa.

111
00:07:55,960 --> 00:08:00,605
Agora esta string tem um formato específico que

112
00:08:00,605 --> 00:08:06,530
permite que ele armazene um número de partes de informações dentro do ID do objeto.

113
00:08:06,530 --> 00:08:11,975
Vejamos a estrutura do próprio ID do objeto no próximo slide.

114
00:08:11,975 --> 00:08:16,325
Como mencionei, o campo ID do objeto em si é

115
00:08:16,325 --> 00:08:22,635
um campo de 12 bytes que armazena informações em um formato específico.

116
00:08:22,635 --> 00:08:26,445
Os primeiros quatro bytes incluem um timestamp,

117
00:08:26,445 --> 00:08:31,760
o timestamp típico Unix na resolução de um segundo.

118
00:08:31,760 --> 00:08:34,340
Então isso é dito nos primeiros quatro bytes.

119
00:08:34,340 --> 00:08:37,580
Em seguida, os próximos três bytes em direção ao ID

120
00:08:37,580 --> 00:08:40,490
da máquina, a máquina na qual o servidor Mongo está sendo executado

121
00:08:40,490 --> 00:08:43,910
e os próximos dois bytes é o ID do processo,

122
00:08:43,910 --> 00:08:47,000
o processo Mongo específico que criou

123
00:08:47,000 --> 00:08:50,674
este documento e, em seguida, o último campo é um incremento.

124
00:08:50,674 --> 00:08:52,490
Agora, como você entende,

125
00:08:52,490 --> 00:08:56,390
o campo de carimbo de data/hora em si está na resolução de um segundo.

126
00:08:56,390 --> 00:09:00,110
Então, se você tiver vários documentos que são armazenados dentro do mesmo segundo,

127
00:09:00,110 --> 00:09:03,735
então o campo de incremento irá distinguir entre os documentos.

128
00:09:03,735 --> 00:09:06,500
Eles incremento campo é um campo auto-incrementante.

129
00:09:06,500 --> 00:09:11,750
Assim, cada novo documento criado dentro de um segundo obterá um novo valor de incremento.

130
00:09:11,750 --> 00:09:14,150
Assim, combinado com esses dois,

131
00:09:14,150 --> 00:09:16,655
você pode facilmente distinguir entre

132
00:09:16,655 --> 00:09:21,550
diferentes documentos armazenados no banco de dados de documentos.

133
00:09:21,550 --> 00:09:28,500
Portanto, isso permite que você forneça claramente um ID exclusivo para cada documento.

134
00:09:28,500 --> 00:09:30,960
Não só isso, dado um ID,

135
00:09:30,960 --> 00:09:34,050
você pode facilmente recuperar informações desse ID.

136
00:09:34,050 --> 00:09:37,460
Assim, por exemplo, você pode obter o objectID e, em seguida, chamar

137
00:09:37,460 --> 00:09:40,880
o método getTimeStamp do ID do objeto e

138
00:09:40,880 --> 00:09:44,655
isso retornará o carimbo de data/hora no formato de data ISO.

139
00:09:44,655 --> 00:09:49,595
Então, isso permitirá que você identifique quando este documento foi criado.

140
00:09:49,595 --> 00:09:52,750
Com esta rápida compreensão do MongoDB,

141
00:09:52,750 --> 00:09:58,700
vamos prosseguir para o exercício onde vamos primeiro instalar MongoDB em nosso computador

142
00:09:58,700 --> 00:10:04,970
e depois interagir com o banco de dados MongoDB usando a ondulação Mongo,

143
00:10:04,970 --> 00:10:09,365
o loop de impressão avaliação leitura que Mongo suporta.

144
00:10:09,365 --> 00:10:12,695
Agora, depois disso, vamos olhar para como podemos acessar

145
00:10:12,695 --> 00:10:19,830
o servidor Mongo de dentro do nosso aplicativo nó na próxima lição.