1 00:00:03,710 --> 00:00:08,700 Permettez-moi de vous donner un aperçu rapide de MongoDB. 2 00:00:08,700 --> 00:00:10,875 Pourquoi MongoDB est-il intéressant ? 3 00:00:10,875 --> 00:00:13,165 En quoi est-il utile pour notre application ? 4 00:00:13,165 --> 00:00:16,290 Et quelles sont quelques-unes des principales caractéristiques de MongoDB 5 00:00:16,290 --> 00:00:19,845 contrairement aux bases de données SQL traditionnelles ? 6 00:00:19,845 --> 00:00:23,190 Donc, ce ne sera pas un traité entier ou une base de données. 7 00:00:23,190 --> 00:00:25,890 Je suppose que vous avez une connaissance suffisante des bases de données. 8 00:00:25,890 --> 00:00:31,050 Donc, ce que je présenterais ce que MongoDB serait facile pour vous de suivre. 9 00:00:31,050 --> 00:00:34,695 D' après votre connaissance préalable des bases de données, 10 00:00:34,695 --> 00:00:40,235 je suppose que vous comprenez déjà que les bases de données sont utilisées pour stocker des données structurées 11 00:00:40,235 --> 00:00:42,515 et vous permettent également d'effectuer 12 00:00:42,515 --> 00:00:46,455 diverses opérations des données, y compris l'interrogation des données, l' 13 00:00:46,455 --> 00:00:48,740 insertion d'enregistrements dans la base de données, la 14 00:00:48,740 --> 00:00:53,870 mise à jour d'un enregistrement existant dans la base de données ou en supprimant un enregistrement de la base de données. 15 00:00:53,870 --> 00:00:58,795 Opérations brutes typiques qui sont prises en charge sur les bases de données. 16 00:00:58,795 --> 00:01:02,870 Structured Query Language ou les bases de données SQL sont 17 00:01:02,870 --> 00:01:07,330 très populaires depuis longtemps comme moyen de stocker des données. 18 00:01:07,330 --> 00:01:13,760 MySQL est un exemple de base de données SQL. 19 00:01:13,760 --> 00:01:16,850 Ils ont été très efficaces pour stocker les 20 00:01:16,850 --> 00:01:20,230 données et répondre ensuite à bon nombre des besoins des applications. 21 00:01:20,230 --> 00:01:27,650 En effet, de nombreux sites Web utilisent déjà des bases de données SQL comme backend pour stocker des données, étant donné 22 00:01:27,650 --> 00:01:30,630 que pourquoi aucune base de données SQL n'est 23 00:01:30,630 --> 00:01:35,610 importante avec de nouveaux types d'applications qui arrivent en ligne. 24 00:01:35,610 --> 00:01:37,850 Il y a une demande croissante de 25 00:01:37,850 --> 00:01:43,170 nouvelles fonctionnalités qui ne sont pas toutes traitées par les bases de données SQL. 26 00:01:43,170 --> 00:01:46,400 Donc, c'est là que la base de données basée sur NoSQL ne sont pas seulement la 27 00:01:46,400 --> 00:01:51,485 base de données SQL gagnent beaucoup de subvention, 28 00:01:51,485 --> 00:01:54,720 MongoDB étant un exemple de cela. 29 00:01:54,720 --> 00:01:58,745 Ainsi, les bases de données NoSQL sont conçues pour 30 00:01:58,745 --> 00:02:03,305 répondre à certaines des lacunes des bases de données SQL. 31 00:02:03,305 --> 00:02:08,935 Les bases de données NoSQL elles-mêmes peuvent être classées en quatre catégories différentes. 32 00:02:08,935 --> 00:02:13,315 Nous avons des bases de données basées sur des documents comme MongoDB, 33 00:02:13,315 --> 00:02:17,820 nous avons les bases de données plus simples basées sur des valeurs clés comme Redis, des 34 00:02:17,820 --> 00:02:24,710 bases de données basées sur des colonnes familiales comme Cassandra et puis les bases de données graphiques plus récentes comme 35 00:02:24,710 --> 00:02:32,210 Neo4J et en effet il y en a plus maintenant sur le marché que ces exemples que j'ai donnés. 36 00:02:32,210 --> 00:02:34,370 Mais bien sûr, dans ce cours, 37 00:02:34,370 --> 00:02:40,050 nous nous concentrerons principalement sur les bases de données basées sur des documents, MongoDB en particulier. 38 00:02:40,050 --> 00:02:44,855 Donc, je vais passer en revue plus sur MongoDB dans le reste de cette conférence. Les 39 00:02:44,855 --> 00:02:48,095 bases de données de documents, comme leur nom l'indique, 40 00:02:48,095 --> 00:02:50,200 sont construites autour de documents. 41 00:02:50,200 --> 00:02:56,530 Un document est une unité d'information autonome et peut être dans de nombreux formats différents, 42 00:02:56,530 --> 00:03:03,425 JSON étant l'un des formats les plus populaires pour stocker des documents dans une base de données de documents. 43 00:03:03,425 --> 00:03:07,535 À titre d'exemple, un document JSON est montré ici et 44 00:03:07,535 --> 00:03:12,215 ce serait quelque chose qui est attribué dans une base de données de documents typique. 45 00:03:12,215 --> 00:03:15,730 Les documents eux-mêmes peuvent être organisés en collections. 46 00:03:15,730 --> 00:03:20,830 Donc, une collection est un groupe de documents et à son tour, 47 00:03:20,830 --> 00:03:26,205 la base de données elle-même peut être considérée comme un ensemble de collections. 48 00:03:26,205 --> 00:03:31,970 Donc, ces termes, « Collections de documents » et « La base de données » se produiront 49 00:03:31,970 --> 00:03:39,290 fréquemment lorsque nous discutons des bases de données de documents et MongoDB en particulier. 50 00:03:39,290 --> 00:03:42,910 Pourquoi les bases de données NoSQL nous intéressent-elles ? 51 00:03:42,910 --> 00:03:45,890 En particulier, l'évolutivité est 52 00:03:45,890 --> 00:03:49,560 l'une des raisons pour lesquelles les bases de données NoSQL ont très bien brillé. 53 00:03:49,560 --> 00:03:52,015 Maintenant, en termes d'évolutivité, 54 00:03:52,015 --> 00:03:53,630 lorsque nous examinons les deux exigences ; la 55 00:03:53,630 --> 00:03:56,990 disponibilité et la cohérence des bases de données, généralement, les 56 00:03:56,990 --> 00:04:02,390 bases de données SQL trouvent très difficile de répondre simultanément aux deux exigences. 57 00:04:02,390 --> 00:04:05,239 Il y a donc un compromis entre la disponibilité et la cohérence. 58 00:04:05,239 --> 00:04:08,690 C' est donc là que les bases de données NoSQL ont beaucoup 59 00:04:08,690 --> 00:04:12,175 plus réussi à répondre aux deux exigences. 60 00:04:12,175 --> 00:04:14,705 C' est là que le troisième aspect mis en évidence ici, 61 00:04:14,705 --> 00:04:17,465 la tolérance de partition, entre également en vigueur. Le 62 00:04:17,465 --> 00:04:23,660 partitionnement d'une base de données SQL puis la distribution n'est pas aussi simple. 63 00:04:23,660 --> 00:04:29,239 Alors qu'une base de données NoSQL est beaucoup plus susceptible 64 00:04:29,239 --> 00:04:34,755 d'être subdivisée puis distribuée sur plusieurs serveurs. 65 00:04:34,755 --> 00:04:40,990 Le deuxième aspect de la popularité des bases de données NoSQL est la facilité de déploiement. 66 00:04:40,990 --> 00:04:43,165 Lorsque vous utilisez une base de données SQL, 67 00:04:43,165 --> 00:04:48,200 il est nécessaire de faire correspondre les enregistrements de votre base de données SQL 68 00:04:48,200 --> 00:04:53,410 à des objets dans votre langue maternelle comme Java ou Javascript et ainsi de suite. 69 00:04:53,410 --> 00:04:56,810 Il y a donc un besoin de mappage relationnel des objets et c'est 70 00:04:56,810 --> 00:05:00,920 là qu'une passerelle intermédiaire doit remplir cette exigence. 71 00:05:00,920 --> 00:05:07,950 Avec une base de données NoSQL comme une base de données basée sur un document stockant des données sous la forme de JSON, 72 00:05:07,950 --> 00:05:12,200 le mappage devient assez simple et c'est l'une des raisons pour lesquelles les 73 00:05:12,200 --> 00:05:17,900 bases de données NoSQL ont été très populaires dans le domaine du développement web. 74 00:05:17,900 --> 00:05:20,680 Venant à MongoDB en particulier, 75 00:05:20,680 --> 00:05:23,820 MongoDB est une base de données de documents. 76 00:05:23,820 --> 00:05:27,150 Le serveur lui-même peut prendre en charge plusieurs bases de données. 77 00:05:27,150 --> 00:05:31,790 Une base de données en particulier est un ensemble de collections 78 00:05:31,790 --> 00:05:36,620 et la collection elle-même comme nous l'avons discuté précédemment est un ensemble de documents. 79 00:05:36,620 --> 00:05:41,705 Ainsi, le document devient l'unité d'information dans le cas de MongoDB. 80 00:05:41,705 --> 00:05:46,825 Le document dans MongoDB n'est rien d'autre qu'un document JSON. 81 00:05:46,825 --> 00:05:53,470 En fait, MongoDB stocke le document sous une forme plus compacte appelée le format BSON. 82 00:05:53,470 --> 00:05:56,495 On en parlera dans la prochaine diapositive. 83 00:05:56,495 --> 00:06:00,175 Bien que MongoDB soit une base de données basée sur un document, 84 00:06:00,175 --> 00:06:04,160 il stocke les documents JSON sous une forme compacte 85 00:06:04,160 --> 00:06:09,125 appelée format BSON ou format JSON binaire. 86 00:06:09,125 --> 00:06:12,920 Maintenant, cela prend en charge le préfixe de longueur sur chaque valeur de sorte 87 00:06:12,920 --> 00:06:16,870 que sauter un champ devient beaucoup plus facile. 88 00:06:16,870 --> 00:06:23,365 Ainsi, comme vous le voyez, MongoDB prend en charge des fonctionnalités supplémentaires qu'une simple base de données de documents. 89 00:06:23,365 --> 00:06:27,835 Les informations sur le type d'une valeur de champ sont également stockées. 90 00:06:27,835 --> 00:06:31,280 De plus, dans le document JSON, des 91 00:06:31,280 --> 00:06:35,405 types primitifs supplémentaires sont stockés qui sont utiles 92 00:06:35,405 --> 00:06:39,860 lorsque vous effectuez des opérations sur la base de données. 93 00:06:39,860 --> 00:06:43,190 Des choses comme le format de date UTC, 94 00:06:43,190 --> 00:06:48,920 il prend également en charge le binaire brut et utilise également un format d'ID d'objet 95 00:06:48,920 --> 00:06:54,790 pour stocker l'ID de chaque document dans la base de données si vous le souhaitez. 96 00:06:54,790 --> 00:06:58,745 Parlons de cela un peu plus en détail dans la diapositive suivante. 97 00:06:58,745 --> 00:07:02,330 Parlons de l'ID d'objet MongoDB. 98 00:07:02,330 --> 00:07:07,000 Chaque document de la base de données MongoDB doit avoir un champ ID, 99 00:07:07,000 --> 00:07:08,985 un champ ID de soulignement, 100 00:07:08,985 --> 00:07:14,055 qui agit comme la clé primaire du document. 101 00:07:14,055 --> 00:07:17,465 Et ce champ est unique pour chaque document. 102 00:07:17,465 --> 00:07:20,810 Le champ ID lui-même peut être utilisé dans de 103 00:07:20,810 --> 00:07:25,955 nombreux formats et un format particulier que MongoDB 104 00:07:25,955 --> 00:07:30,020 attribue automatiquement au cas où vous ne choisiriez pas d'utiliser votre propre champ ID 105 00:07:30,020 --> 00:07:35,350 est l'ID d'objet créé par défaut par MongoDB. 106 00:07:35,350 --> 00:07:37,550 Ainsi, l'ID d'objet lui-même est 107 00:07:37,550 --> 00:07:43,660 un élément d'information structuré mais est stocké comme l'ID du document. 108 00:07:43,660 --> 00:07:47,825 Par exemple, le champ ID qui est automatiquement 109 00:07:47,825 --> 00:07:52,390 attribué par Mongo dans le cas où vous ne spécifiez pas de champ ID, 110 00:07:52,390 --> 00:07:55,960 contient l'ID d'objet sous la forme d'une longue chaîne. 111 00:07:55,960 --> 00:08:00,605 Maintenant, cette chaîne a un format spécifique qui 112 00:08:00,605 --> 00:08:06,530 lui permet de stocker un certain nombre d'informations dans l'ID de l'objet. 113 00:08:06,530 --> 00:08:11,975 Regardons la structure de l'ID d'objet lui-même dans la diapositive suivante. 114 00:08:11,975 --> 00:08:16,325 Comme je l'ai mentionné, le champ ID de l'objet lui-même est 115 00:08:16,325 --> 00:08:22,635 un champ de 12 octets qui stocke des informations dans un format spécifique. 116 00:08:22,635 --> 00:08:26,445 Les quatre premiers octets incluent un horodatage, 117 00:08:26,445 --> 00:08:31,760 l'horodatage standard Unix dans la résolution d'une seconde. 118 00:08:31,760 --> 00:08:34,340 Donc, cela est dit dans les quatre premiers octets. 119 00:08:34,340 --> 00:08:37,580 Ensuite, les trois octets suivants vers l'ID de machine, 120 00:08:37,580 --> 00:08:40,490 la machine sur laquelle le serveur Mongo est en cours d'exécution 121 00:08:40,490 --> 00:08:43,910 et les deux octets suivants sont l'ID de processus, 122 00:08:43,910 --> 00:08:47,000 le processus Mongo spécifique qui a créé 123 00:08:47,000 --> 00:08:50,674 ce document, puis le dernier champ est un incrément. 124 00:08:50,674 --> 00:08:52,490 Maintenant, comme vous le comprenez, 125 00:08:52,490 --> 00:08:56,390 le champ horodatage lui-même est à la résolution d'une seconde. 126 00:08:56,390 --> 00:09:00,110 Donc, si vous avez plusieurs documents qui sont stockés dans la même seconde, 127 00:09:00,110 --> 00:09:03,735 alors le champ d'incrémentation distinguera les documents. 128 00:09:03,735 --> 00:09:06,500 Ils incrémentent le champ est un champ auto-incrémentant. 129 00:09:06,500 --> 00:09:11,750 Ainsi, chaque nouveau document créé en une seconde obtiendra une nouvelle valeur d'incrément. 130 00:09:11,750 --> 00:09:14,150 Ainsi, combiné avec ces deux documents, 131 00:09:14,150 --> 00:09:16,655 vous pouvez facilement distinguer les 132 00:09:16,655 --> 00:09:21,550 différents documents stockés dans votre base de données de documents. 133 00:09:21,550 --> 00:09:28,500 Cela vous permet donc de donner clairement un identifiant unique à chaque document. 134 00:09:28,500 --> 00:09:30,960 Non seulement cela, avec un ID, 135 00:09:30,960 --> 00:09:34,050 vous pouvez facilement récupérer des informations à partir de cet ID. 136 00:09:34,050 --> 00:09:37,460 Ainsi, par exemple, vous pouvez obtenir l'ObjectID, puis appeler 137 00:09:37,460 --> 00:09:40,880 la méthode getTimeStamp de l'ID d'objet et 138 00:09:40,880 --> 00:09:44,655 cela retournera l'horodatage au format de date ISO. 139 00:09:44,655 --> 00:09:49,595 Cela vous permettra donc d'identifier quand ce document a été créé. 140 00:09:49,595 --> 00:09:52,750 Avec cette compréhension rapide de MongoDB, 141 00:09:52,750 --> 00:09:58,700 continuons à l'exercice où nous allons d'abord installer MongoDB sur notre ordinateur 142 00:09:58,700 --> 00:10:04,970 et ensuite interagir avec la base de données MongoDB en utilisant l'ondulation Mongo, 143 00:10:04,970 --> 00:10:09,365 la boucle d'impression d'évaluation de lecture que Mongo prend en charge. 144 00:10:09,365 --> 00:10:12,695 Maintenant, nous allons examiner comment nous pouvons accéder 145 00:10:12,695 --> 00:10:19,830 au serveur Mongo à partir de notre application de nœud dans la prochaine leçon.