1 00:00:03,710 --> 00:00:08,700 Lassen Sie mich Ihnen einen kurzen Überblick über MongoDB geben. 2 00:00:08,700 --> 00:00:10,875 Warum ist MongoDB interessant? 3 00:00:10,875 --> 00:00:13,165 Wie ist es nützlich für unsere Anwendung? 4 00:00:13,165 --> 00:00:16,290 Und was sind einige der wichtigsten Merkmale von MongoDB im 5 00:00:16,290 --> 00:00:19,845 Gegensatz zu herkömmlichen SQL-Datenbanken? 6 00:00:19,845 --> 00:00:23,190 So wird dies nicht eine ganze Verträge oder Datenbanken sein. 7 00:00:23,190 --> 00:00:25,890 Ich gehe davon aus, dass Sie über ausreichende Kenntnisse der Datenbanken verfügen. 8 00:00:25,890 --> 00:00:31,050 Also, was ich vorstellen würde, was MongoDB wäre einfach für Sie zu folgen. 9 00:00:31,050 --> 00:00:34,695 Aus Ihren Vorkenntnissen über Datenbanken 10 00:00:34,695 --> 00:00:40,235 gehe ich davon aus, dass Sie bereits verstehen, dass Datenbanken verwendet werden, um strukturierte Daten 11 00:00:40,235 --> 00:00:42,515 zu speichern, und es Ihnen auch ermöglichen, 12 00:00:42,515 --> 00:00:46,455 verschiedene Operationen der Daten durchzuführen, einschließlich der Abfrage der Daten, 13 00:00:46,455 --> 00:00:48,740 Einfügen von Datensätzen in die Datenbank, 14 00:00:48,740 --> 00:00:53,870 Aktualisierung eines vorhandenen Datensatzes in der Datenbank oder Löschen eines Datensatzes aus der Datenbank. 15 00:00:53,870 --> 00:00:58,795 Die typischen crud-Operationen, die auf Datenbanken unterstützt werden. 16 00:00:58,795 --> 00:01:02,870 Structured Query Language oder SQL-basierte Datenbanken sind 17 00:01:02,870 --> 00:01:07,330 seit langem als Mittel zum Speichern von Daten sehr beliebt. 18 00:01:07,330 --> 00:01:13,760 Die MySQL ist ein Beispiel für SQL-basierte Datenbank. 19 00:01:13,760 --> 00:01:16,850 Sie waren sehr effektiv, um 20 00:01:16,850 --> 00:01:20,230 Daten zu speichern und dann viele der Anforderungen von Anwendungen zu adressieren. 21 00:01:20,230 --> 00:01:27,650 Tatsächlich verwenden viele Websites bereits SQL-Datenbanken als Backend zum Speichern von Daten 22 00:01:27,650 --> 00:01:30,630 , da daher keine SQL-Datenbanken 23 00:01:30,630 --> 00:01:35,610 bei neuen Arten von Anwendungen wichtig sind, die online geschaltet werden. 24 00:01:35,610 --> 00:01:37,850 Es gibt eine steigende Nachfrage nach 25 00:01:37,850 --> 00:01:43,170 neuen Funktionen, die nicht alle SQL-basierten Datenbanken adressieren können. 26 00:01:43,170 --> 00:01:46,400 Dies ist also, wo die NoSQL-basierte Datenbank nicht nur 27 00:01:46,400 --> 00:01:51,485 SQL-basierte Datenbank eine Menge Grant gewinnen, 28 00:01:51,485 --> 00:01:54,720 MongoDB ist ein Beispiel dafür. 29 00:01:54,720 --> 00:01:58,745 Daher sind die NoSQL-Datenbanken so konzipiert, dass 30 00:01:58,745 --> 00:02:03,305 einige der Mängel von SQL-basierten Datenbanken behoben werden. 31 00:02:03,305 --> 00:02:08,935 Die NoSQL-Datenbanken selbst können in vier verschiedene Kategorien eingeteilt werden. 32 00:02:08,935 --> 00:02:13,315 Wir haben dokumentbasierte Datenbanken wie MongoDB, 33 00:02:13,315 --> 00:02:17,820 wir haben die einfacheren Schlüsselwert-basierten Datenbanken wie Redis, 34 00:02:17,820 --> 00:02:24,710 spalten-familienbasierte Datenbanken wie Cassandra und dann die neueren Graph-Datenbanken wie 35 00:02:24,710 --> 00:02:32,210 Neo4J und tatsächlich gibt es jetzt mehr auf dem Markt als diese Beispiele, die ich gegeben habe. 36 00:02:32,210 --> 00:02:34,370 Aber natürlich 37 00:02:34,370 --> 00:02:40,050 werden wir uns in diesem Kurs vor allem auf dokumentbasierte Datenbanken konzentrieren, insbesondere MongoDB. 38 00:02:40,050 --> 00:02:44,855 Also werde ich mehr über MongoDB im Rest dieser Vorlesung überprüfen. 39 00:02:44,855 --> 00:02:48,095 Dokumentdatenbanken 40 00:02:48,095 --> 00:02:50,200 sind, wie der Name schon sagt, um Dokumente herum aufgebaut. 41 00:02:50,200 --> 00:02:56,530 Ein Dokument ist eine eigenständige Informationseinheit und kann in vielen verschiedenen Formaten vorliegen. 42 00:02:56,530 --> 00:03:03,425 JSON ist eines der gängigsten Formate zum Speichern von Dokumenten in einer Dokumentdatenbank. 43 00:03:03,425 --> 00:03:07,535 Als Beispiel wird hier ein JSON-Dokument gezeigt 44 00:03:07,535 --> 00:03:12,215 , das in einer typischen Dokumentdatenbank verliehen wird. 45 00:03:12,215 --> 00:03:15,730 Dokumente selbst können in Sammlungen organisiert werden. 46 00:03:15,730 --> 00:03:20,830 Eine Sammlung ist also eine Gruppe von Dokumenten und wiederum 47 00:03:20,830 --> 00:03:26,205 kann die Datenbank selbst als eine Reihe von Sammlungen betrachtet werden. 48 00:03:26,205 --> 00:03:31,970 So werden diese Begriffe „Dokumente Sammlungen“ und „Die Datenbank“ 49 00:03:31,970 --> 00:03:39,290 häufig auftreten, wenn wir über Dokumentdatenbanken und MongoDB im Besonderen diskutieren. 50 00:03:39,290 --> 00:03:42,910 Warum sind NoSQL-Datenbanken von Interesse für uns? 51 00:03:42,910 --> 00:03:45,890 Insbesondere die Skalierbarkeit ist einer 52 00:03:45,890 --> 00:03:49,560 der Gründe, warum NoSQL-Datenbanken sehr gut glänzen. 53 00:03:49,560 --> 00:03:52,015 Im Hinblick auf die Skalierbarkeit, 54 00:03:52,015 --> 00:03:53,630 wenn wir uns die beiden Anforderungen ansehen: 55 00:03:53,630 --> 00:03:56,990 Verfügbarkeit und Konsistenz der Datenbanken, in der Regel, 56 00:03:56,990 --> 00:04:02,390 finden SQL-Datenbanken es sehr schwierig, beide Anforderungen gleichzeitig zu erfüllen. 57 00:04:02,390 --> 00:04:05,239 Es gibt also einen Kompromiss zwischen Verfügbarkeit und Konsistenz. 58 00:04:05,239 --> 00:04:08,690 Dies ist, wo NoSQL-Datenbanken viel 59 00:04:08,690 --> 00:04:12,175 erfolgreicher waren, um beide Anforderungen zu erfüllen. 60 00:04:12,175 --> 00:04:14,705 Hier 61 00:04:14,705 --> 00:04:17,465 tritt auch der dritte hier hervorgehobene Aspekt, Partitionstoleranz, in Kraft. 62 00:04:17,465 --> 00:04:23,660 Jetzt ist das Partitionieren einer SQL-Datenbank und das anschließende Verteilen nicht so einfach. 63 00:04:23,660 --> 00:04:29,239 Während eine NoSQL-Datenbank viel zugänglicher ist 64 00:04:29,239 --> 00:04:34,755 , unterteilt und dann über mehrere Server verteilt zu werden. 65 00:04:34,755 --> 00:04:40,990 Der zweite Aspekt, warum NoSQL-Datenbanken populär waren, ist die einfache Bereitstellung. 66 00:04:40,990 --> 00:04:43,165 Wenn Sie eine SQL-Datenbank verwenden, 67 00:04:43,165 --> 00:04:48,200 müssen Sie die Datensätze in Ihrer SQL-Datenbank wieder mit 68 00:04:48,200 --> 00:04:53,410 Objekten in Ihrer Muttersprache wie Java oder Javascript usw. abgleichen. 69 00:04:53,410 --> 00:04:56,810 Es besteht also Bedarf an objekt-relationalen Mapping 70 00:04:56,810 --> 00:05:00,920 , und hier muss ein Zwischengateway diese Anforderung erfüllen. 71 00:05:00,920 --> 00:05:07,950 Mit einer NoSQL-Datenbank wie einer dokumentbasierten Datenbank, die Daten in Form von JSON speichert, 72 00:05:07,950 --> 00:05:12,200 wird das Mapping ziemlich einfach, und das ist einer der Gründe, warum 73 00:05:12,200 --> 00:05:17,900 NoSQL-Datenbanken im Bereich der Webentwicklung sehr beliebt waren. 74 00:05:17,900 --> 00:05:20,680 MongoDB kommt insbesondere zu 75 00:05:20,680 --> 00:05:23,820 MongoDB, ist eine Dokumentdatenbank. 76 00:05:23,820 --> 00:05:27,150 Der Server selbst kann mehrere Datenbanken unterstützen. 77 00:05:27,150 --> 00:05:31,790 Eine Datenbank ist insbesondere eine Reihe von Sammlungen 78 00:05:31,790 --> 00:05:36,620 und die Sammlung selbst, wie wir bereits besprochen haben, ist eine Reihe von Dokumenten. 79 00:05:36,620 --> 00:05:41,705 So wird das Dokument zur Informationseinheit im Falle von MongoDB. 80 00:05:41,705 --> 00:05:46,825 Das Dokument in MongoDB ist nichts anderes als ein JSON-Dokument. 81 00:05:46,825 --> 00:05:53,470 In der Tat speichert MongoDB das Dokument in einer kompakteren Form, die als BSON-Format bezeichnet wird. 82 00:05:53,470 --> 00:05:56,495 Darüber reden wir auf der nächsten Folie. 83 00:05:56,495 --> 00:06:00,175 Während MongoDB eine dokumentbasierte Datenbank ist, 84 00:06:00,175 --> 00:06:04,160 speichert sie die JSON-Dokumente in einer kompakten Form, 85 00:06:04,160 --> 00:06:09,125 die als BSON-Format oder binäres JSON-Format bezeichnet wird. 86 00:06:09,125 --> 00:06:12,920 Jetzt unterstützt dies Längenpräfix für jeden Wert 87 00:06:12,920 --> 00:06:16,870 , so dass das Überspringen eines Feldes viel einfacher wird. 88 00:06:16,870 --> 00:06:23,365 Wie Sie sehen, unterstützt MongoDB zusätzliche Funktionen als eine einfache Dokumentdatenbank. 89 00:06:23,365 --> 00:06:27,835 Die Informationen über den Typ eines Feldwerts werden ebenfalls gespeichert. 90 00:06:27,835 --> 00:06:31,280 Darüber hinaus 91 00:06:31,280 --> 00:06:35,405 werden im JSON-Dokument zusätzliche primitive Typen gespeichert, die nützlich sind, 92 00:06:35,405 --> 00:06:39,860 wenn Sie Operationen in der Datenbank ausführen. 93 00:06:39,860 --> 00:06:43,190 Dinge wie das UTC-Datumsformat, 94 00:06:43,190 --> 00:06:48,920 es unterstützt auch rohe Binärdateien und verwendet auch ein Objekt-ID-Format, um 95 00:06:48,920 --> 00:06:54,790 die ID jedes Dokuments in der Datenbank zu speichern, wenn Sie möchten. 96 00:06:54,790 --> 00:06:58,745 Lassen Sie uns auf der nächsten Folie etwas detaillierter darüber sprechen. 97 00:06:58,745 --> 00:07:02,330 Lassen Sie uns über die MongoDB-Objekt-ID sprechen. 98 00:07:02,330 --> 00:07:07,000 Jedes Dokument in der MongoDB-Datenbank muss über ein ID-Feld verfügen, 99 00:07:07,000 --> 00:07:08,985 ein Unterstrich-ID-Feld, 100 00:07:08,985 --> 00:07:14,055 das als Primärschlüssel für das Dokument fungiert. 101 00:07:14,055 --> 00:07:17,465 Und dieses Feld ist für jedes Dokument eindeutig. 102 00:07:17,465 --> 00:07:20,810 Das ID-Feld selbst kann in 103 00:07:20,810 --> 00:07:25,955 vielen Formaten verwendet werden, und ein bestimmtes Format, das MongoDB automatisch 104 00:07:25,955 --> 00:07:30,020 zuweist, falls Sie nicht Ihr eigenes ID-Feld verwenden möchten, 105 00:07:30,020 --> 00:07:35,350 ist die Objekt-ID, die standardmäßig von MongoDB erstellt wird. 106 00:07:35,350 --> 00:07:37,550 Die Objekt-ID selbst ist also 107 00:07:37,550 --> 00:07:43,660 eine strukturierte Information, wird aber als ID des Dokuments gespeichert. 108 00:07:43,660 --> 00:07:52,390 Beispielsweise 109 00:07:52,390 --> 00:07:55,960 enthält das ID-Feld, das von Mongo automatisch zugewiesen wird, falls Sie kein ID-Feld angeben, die Objekt-ID in Form eines langen Strings. 110 00:07:55,960 --> 00:08:00,605 Nun hat diese Zeichenfolge ein bestimmtes Format, das 111 00:08:00,605 --> 00:08:06,530 es ermöglicht, eine Reihe von Informationen innerhalb der Objekt-ID zu speichern. 112 00:08:06,530 --> 00:08:11,975 Schauen wir uns die Struktur der Objekt-ID selbst in der nächsten Folie an. 113 00:08:11,975 --> 00:08:16,325 Wie bereits erwähnt, ist das Objekt-ID-Feld selbst 114 00:08:16,325 --> 00:08:22,635 ein 12-Byte-Feld, das Informationen in einem bestimmten Format speichert. 115 00:08:22,635 --> 00:08:26,445 Die ersten vier Bytes enthalten einen Zeitstempel, 116 00:08:26,445 --> 00:08:31,760 den typischen Unix-Zeitstempel in der Auflösung einer Sekunde. 117 00:08:31,760 --> 00:08:34,340 Dies wird also in den ersten vier Bytes erzählt. 118 00:08:34,340 --> 00:08:37,580 Dann sind die nächsten drei Bytes in Richtung der Computer-ID, 119 00:08:37,580 --> 00:08:40,490 der Computer, auf dem der Mongo-Server läuft 120 00:08:40,490 --> 00:08:43,910 und die nächsten zwei Bytes die Prozess-ID, 121 00:08:43,910 --> 00:08:47,000 der spezifische Mongo-Prozess, der 122 00:08:47,000 --> 00:08:50,674 dieses Dokument erstellt hat, und dann das letzte Feld ist ein Inkrement. 123 00:08:50,674 --> 00:08:52,490 Nun, wie Sie verstehen, 124 00:08:52,490 --> 00:08:56,390 ist das Zeitstempelfeld selbst in der Auflösung einer Sekunde. 125 00:08:56,390 --> 00:09:00,110 Wenn Sie also mehrere Dokumente haben, die innerhalb derselben Sekunde gespeichert sind, 126 00:09:00,110 --> 00:09:03,735 unterscheidet das Inkrementfeld zwischen den Dokumenten. 127 00:09:03,735 --> 00:09:06,500 Sie inkrementieren Feld ist ein selbstinkrementierendes Feld. 128 00:09:06,500 --> 00:09:11,750 So erhält jedes neue Dokument, das innerhalb einer Sekunde erstellt wird, einen neuen Inkrementwert. 129 00:09:11,750 --> 00:09:14,150 Zusammen mit diesen beiden 130 00:09:14,150 --> 00:09:16,655 können Sie problemlos zwischen 131 00:09:16,655 --> 00:09:21,550 verschiedenen Dokumenten unterscheiden, die in Ihrer Dokumentdatenbank gespeichert sind. 132 00:09:21,550 --> 00:09:28,500 Auf diese Weise können Sie jedem Dokument eindeutig eine eindeutige ID zuweisen. 133 00:09:28,500 --> 00:09:30,960 Nicht nur das, wenn Sie eine ID 134 00:09:30,960 --> 00:09:34,050 haben, können Sie leicht Informationen von dieser ID abrufen. 135 00:09:34,050 --> 00:09:37,460 So können Sie beispielsweise die ObjectID erhalten und dann die 136 00:09:37,460 --> 00:09:40,880 GetTimeStamp-Methode der Objekt-ID aufrufen, und 137 00:09:40,880 --> 00:09:44,655 dies gibt den Zeitstempel im ISO-Datumsformat zurück. 138 00:09:44,655 --> 00:09:49,595 So können Sie erkennen, wann dieses Dokument erstellt wurde. 139 00:09:49,595 --> 00:09:52,750 Mit diesem schnellen Verständnis von MongoDB, 140 00:09:52,750 --> 00:09:58,700 lassen Sie uns mit der Übung fortfahren, wo wir zuerst MongoDB auf unserem Computer installieren 141 00:09:58,700 --> 00:10:04,970 und danach mit der MongoDB-Datenbank interagieren werden, indem wir die Mongo Ripple verwenden, 142 00:10:04,970 --> 00:10:09,365 die lesen evaluieren Druckschleife, die Mongo unterstützt. 143 00:10:09,365 --> 00:10:12,695 Danach werden wir uns in der 144 00:10:12,695 --> 00:10:19,830 nächsten Lektion ansehen, wie wir aus unserer Knotenanwendung auf den Mongo-Server zugreifen können.