1 00:00:00,910 --> 00:00:02,310 ‫Jonas: Willkommen zurück. 2 00:00:02,310 --> 00:00:04,110 ‫Lassen Sie uns 3 00:00:04,110 --> 00:00:07,540 ‫nun ein wenig über die Leseleistung in MongoDB sprechen, 4 00:00:07,540 --> 00:00:10,630 ‫warum sogenannte Indizes so wichtig sind und wie 5 00:00:10,630 --> 00:00:13,053 ‫wir sie tatsächlich selbst erstellen können. 6 00:00:14,560 --> 00:00:18,540 ‫Und ich möchte diese Demonstration über Indizes mit einer 7 00:00:18,540 --> 00:00:21,873 ‫einfachen Abfrage auf allen unseren Touren beginnen. 8 00:00:23,500 --> 00:00:26,550 ‫Kommen wir also hierher um alle Touren 9 00:00:26,550 --> 00:00:28,820 ‫zu bekommen und ich 10 00:00:30,190 --> 00:00:33,803 ‫werde auch für einen Preis unter 1.000 filtern. 11 00:00:35,400 --> 00:00:39,393 ‫Okay und mal sehen. 12 00:00:40,900 --> 00:00:43,970 ‫Ja, wir bekommen also drei Ergebnisse zurück, in Ordnung. 13 00:00:43,970 --> 00:00:45,950 ‫Und das ist wichtig zu bedenken 14 00:00:45,950 --> 00:00:48,230 ‫für das, was ich Ihnen als nächstes zeigen 15 00:00:48,230 --> 00:00:51,200 ‫werde, nämlich dass wir tatsächlich auch ein paar Statistiken über 16 00:00:51,200 --> 00:00:53,070 ‫die Abfrage selbst erhalten können. 17 00:00:53,070 --> 00:00:56,770 ‫Gehen wir hier also grundsätzlich zur Handler-Funktion. 18 00:00:56,770 --> 00:01:01,523 ‫Und so erinnert sich das gerade jetzt in die Handler-Fabrik. 19 00:01:02,620 --> 00:01:06,033 ‫Richtig, das ist es also, ich glaube, es 20 00:01:08,100 --> 00:01:09,410 ‫ist ganz unten. 21 00:01:09,410 --> 00:01:12,000 ‫Ja, also holen Sie sich alle Factory-Funktionen, 22 00:01:12,000 --> 00:01:14,290 ‫die diesen Handler erstellen, der 23 00:01:14,290 --> 00:01:16,940 ‫für die gerade durchgeführte Abfrage aufgerufen wird. 24 00:01:16,940 --> 00:01:18,360 ‫Und hier zur 25 00:01:18,360 --> 00:01:21,053 ‫Abfrage füge ich jetzt tatsächlich eine EXPLAIN-Methode hinzu. 26 00:01:23,640 --> 00:01:28,300 ‫Okay, nach der Abfrage rufen wir dann "in Ordnung" an. 27 00:01:28,300 --> 00:01:30,603 ‫Und schauen wir uns das an. 28 00:01:33,710 --> 00:01:36,770 ‫Und so erhalten wir jetzt ein ganz anderes 29 00:01:36,770 --> 00:01:39,490 ‫Ergebnis, das im Grunde diese Statistik ist. 30 00:01:39,490 --> 00:01:41,920 ‫Jetzt ist viel Zeug drin. 31 00:01:41,920 --> 00:01:43,030 ‫Aber 32 00:01:43,030 --> 00:01:48,030 ‫was mich wirklich interessiert, sind diese Ausführungsstatistiken, okay. 33 00:01:48,110 --> 00:01:50,230 ‫Sie können hier also 34 00:01:50,230 --> 00:01:52,420 ‫sehen, dass drei Dokumente zurückgegeben wurden. 35 00:01:52,420 --> 00:01:55,130 ‫Und genau das ist das Ergebnis, das wir vorher bekommen haben. 36 00:01:55,130 --> 00:01:58,030 ‫Also bevor du das richtig erklärst. 37 00:01:58,030 --> 00:02:00,230 ‫Aber was hier wirklich wichtig 38 00:02:00,230 --> 00:02:01,460 ‫ist, ist, 39 00:02:01,460 --> 00:02:05,180 ‫dass die Anzahl der untersuchten Dokumente neun beträgt, okay. 40 00:02:05,180 --> 00:02:07,970 ‫Und das bedeutet, dass MongoDB alle neun 41 00:02:07,970 --> 00:02:11,200 ‫Dokumente untersuchen, also im Wesentlichen scannen musste, um 42 00:02:11,200 --> 00:02:13,780 ‫die richtigen drei zu finden. 43 00:02:13,780 --> 00:02:17,260 ‫Also die drei, die der Abfrage entsprechen, sind in Ordnung. 44 00:02:17,260 --> 00:02:20,320 ‫Und das ist also überhaupt nicht effizient, oder? 45 00:02:20,320 --> 00:02:21,900 ‫In dieser Größenordnung 46 00:02:21,900 --> 00:02:25,670 ‫mit nur neun Dokumenten macht das natürlich keinen Unterschied. 47 00:02:25,670 --> 00:02:27,740 ‫Aber wenn wir hier Hunderttausende 48 00:02:27,740 --> 00:02:30,020 ‫oder sogar Millionen von Dokumenten hätten, 49 00:02:30,020 --> 00:02:32,010 ‫dann würde dies 50 00:02:32,010 --> 00:02:34,390 ‫die Leseleistung dieser Abfrage erheblich beeinträchtigen. 51 00:02:34,390 --> 00:02:37,850 ‫Auch hier wird dies in dieser Anwendung nicht der Fall sein, aber 52 00:02:37,850 --> 00:02:41,210 ‫möglicherweise in einer App, die Sie eines Tages erstellen werden. 53 00:02:41,210 --> 00:02:44,150 ‫Sie müssen also wirklich etwas über Indizes lernen. 54 00:02:44,150 --> 00:02:46,290 ‫Denn mit Indizes werden 55 00:02:46,290 --> 00:02:48,530 ‫wir dieses Problem irgendwie lösen können. 56 00:02:48,530 --> 00:02:53,020 ‫So können wir Indizes für bestimmte Felder in einer Sammlung erstellen. 57 00:02:53,020 --> 00:02:55,980 ‫Beispielsweise erstellt Mongo standardmäßig automatisch einen 58 00:02:55,980 --> 00:02:58,640 ‫Index für das ID-Feld. 59 00:02:58,640 --> 00:03:02,920 ‫Und sehen wir uns das tatsächlich in Compass an. 60 00:03:02,920 --> 00:03:07,280 ‫Zum Beispiel haben wir hier bei allen Touren die Registerkarte Indizes. 61 00:03:07,280 --> 00:03:09,580 ‫Bis zu diesem Zeitpunkt waren wir also nur 62 00:03:09,580 --> 00:03:10,810 ‫hier im Dokumenten-Tab, 63 00:03:10,810 --> 00:03:13,550 ‫aber wie Sie sehen, haben wir hier viele verschiedene 64 00:03:13,550 --> 00:03:15,690 ‫Dinge, und einer davon sind die Indizes. 65 00:03:15,690 --> 00:03:20,410 ‫Und so sehen Sie wieder, dass wir standardmäßig einen ID-Index haben. 66 00:03:20,410 --> 00:03:23,860 ‫Und dieser ID-Index ist dann im Grunde eine 67 00:03:23,860 --> 00:03:26,380 ‫geordnete Liste aller IDs, die irgendwo 68 00:03:26,380 --> 00:03:28,890 ‫außerhalb der Sammlung gespeichert werden. 69 00:03:28,890 --> 00:03:30,750 ‫Und Sie können hier 70 00:03:30,750 --> 00:03:35,190 ‫tatsächlich eine Größe sehen, die 36 Kilobyte hat, dieser Index in Ordnung. 71 00:03:35,190 --> 00:03:37,660 ‫Und dieser Index ist äußerst nützlich. 72 00:03:37,660 --> 00:03:39,830 ‫Denn wenn Dokumente von 73 00:03:39,830 --> 00:03:44,140 ‫der ID abgefragt werden, durchsucht MongoDB diesen geordneten Index, anstatt 74 00:03:44,140 --> 00:03:46,390 ‫die gesamte Sammlung zu durchsuchen 75 00:03:46,390 --> 00:03:48,660 ‫und alle Dokumente einzeln zu durchsuchen, 76 00:03:48,660 --> 00:03:50,890 ‫was natürlich viel langsamer ist. 77 00:03:50,890 --> 00:03:54,440 ‫Also wieder ohne Index muss Mongo sich 78 00:03:54,440 --> 00:03:56,650 ‫jedes Dokument einzeln ansehen. 79 00:03:56,650 --> 00:03:59,830 ‫Aber mit einem Index für das Feld, das 80 00:03:59,830 --> 00:04:02,810 ‫wir abfragen, wird dieser Prozess viel effizienter. 81 00:04:02,810 --> 00:04:05,420 ‫Das ist also ziemlich schlau, oder? 82 00:04:05,420 --> 00:04:08,230 ‫Und natürlich können wir unsere eigenen Indizes für 83 00:04:08,230 --> 00:04:10,890 ‫Felder setzen, die wir sehr oft abfragen. 84 00:04:10,890 --> 00:04:13,430 ‫Lassen Sie uns das also mit dem 85 00:04:13,430 --> 00:04:15,830 ‫Preisfeld machen, nach dem wir gerade 86 00:04:15,830 --> 00:04:18,800 ‫abgefragt haben, weil ich glaube, dass es eines der 87 00:04:18,800 --> 00:04:21,770 ‫wichtigsten ist, nach dem die Leute fragen, okay. 88 00:04:21,770 --> 00:04:25,100 ‫Und so funktioniert es. 89 00:04:25,100 --> 00:04:30,030 ‫Wir müssen also direkt zum Tourmodell gehen. 90 00:04:30,030 --> 00:04:33,290 ‫Und dann machen wir es gleich hier nach dieser inneren Deklaration 91 00:04:34,370 --> 00:04:37,097 ‫und wir sagen tourschema. Index ok. 92 00:04:42,960 --> 00:04:45,600 ‫Und dann ein Objekt mit dem Namen des Feldes 93 00:04:47,070 --> 00:04:49,470 ‫und denken Sie daran, wie ich sagte, 94 00:04:49,470 --> 00:04:54,470 ‫wir würden den Index auf den Preis setzen und dann entweder eine Eins oder eine Minus-Eins. 95 00:04:54,500 --> 00:04:57,100 ‫Und eine Eins bedeutet, dass wir den 96 00:04:57,100 --> 00:04:58,660 ‫Preisindex in aufsteigender Reihenfolge 97 00:04:58,660 --> 00:05:02,120 ‫sortieren, während die Minus-Eins für absteigende Reihenfolge in Ordnung steht. 98 00:05:02,120 --> 00:05:05,520 ‫Und es gibt tatsächlich auch andere Arten von Indizes, wie zum 99 00:05:05,520 --> 00:05:08,280 ‫Beispiel für Text oder für Geodaten, aber das 100 00:05:08,280 --> 00:05:10,260 ‫werden wir etwas später sehen. 101 00:05:10,260 --> 00:05:13,360 ‫Okay, speichern wir es jetzt 102 00:05:13,360 --> 00:05:16,633 ‫und versuchen Sie unsere Abfrage erneut. 103 00:05:17,820 --> 00:05:20,190 ‫Und tatsächlich werde ich es hier ein paar 104 00:05:20,190 --> 00:05:22,860 ‫Mal tun, um sicherzustellen, dass der Index wirklich gesetzt ist. 105 00:05:22,860 --> 00:05:26,950 ‫Denn manchmal ist es nicht sofort eingestellt. 106 00:05:26,950 --> 00:05:28,860 ‫Aber werfen wir jetzt einen Blick hier. 107 00:05:28,860 --> 00:05:33,140 ‫Und so bekommen wir zwar immer noch unsere Zahl der 108 00:05:33,140 --> 00:05:36,260 ‫zurückgeschickten drei, aber diesmal waren auch 109 00:05:36,260 --> 00:05:39,490 ‫nur drei Dokumente, die geprüft, also eingescannt wurden. 110 00:05:39,490 --> 00:05:41,540 ‫Und das beweist, dass wir mit diesem 111 00:05:41,540 --> 00:05:44,310 ‫Index im Grunde genau das erreicht haben, was wir wollten. 112 00:05:44,310 --> 00:05:47,370 ‫Vorher mussten wir also alle neun Dokumente scannen und jetzt 113 00:05:47,370 --> 00:05:50,230 ‫muss die Engine nur noch die drei Dokumente scannen, 114 00:05:50,230 --> 00:05:51,870 ‫die auch tatsächlich zurückgegeben werden. 115 00:05:51,870 --> 00:05:54,080 ‫Und wieder, weil ihre Preise 116 00:05:54,080 --> 00:05:56,330 ‫jetzt in diesem Index geordnet sind. 117 00:05:56,330 --> 00:05:58,890 ‫Das macht es der MongoDB-Engine 118 00:05:58,890 --> 00:06:01,870 ‫viel einfacher und schneller, sie zu finden. 119 00:06:01,870 --> 00:06:04,883 ‫Und so ist das natürlich ein enormer Leistungsgewinn. 120 00:06:05,930 --> 00:06:09,300 ‫Schauen wir uns jetzt auch Compass hier an und 121 00:06:09,300 --> 00:06:13,060 ‫laden wir tatsächlich die gesamte Datenbank neu, und jetzt sollte 122 00:06:13,060 --> 00:06:14,890 ‫sie eigentlich hier sein, 123 00:06:14,890 --> 00:06:17,750 ‫aber aus irgendeinem Grund ist sie es nicht. 124 00:06:17,750 --> 00:06:19,823 ‫Versuchen wir vielleicht, die Dokumente neu zu laden. 125 00:06:21,040 --> 00:06:22,433 ‫Vielleicht taucht es dann auf. 126 00:06:23,910 --> 00:06:26,963 ‫Nicht wirklich, lassen Sie uns auch das Schema analysieren, 127 00:06:28,080 --> 00:06:29,260 ‫und darüber werden 128 00:06:29,260 --> 00:06:30,583 ‫wir etwas später sprechen. 129 00:06:31,420 --> 00:06:34,970 ‫Aber wie Sie sehen, haben wir immer noch nur diese beiden Indizes. 130 00:06:34,970 --> 00:06:37,760 ‫Aber das macht nichts, denn wir wissen 131 00:06:37,760 --> 00:06:40,760 ‫ja schon, dass der Index tatsächlich funktioniert, oder? 132 00:06:40,760 --> 00:06:41,830 ‫Es ist also 133 00:06:41,830 --> 00:06:45,450 ‫völlig normal, dass die Aktualisierung manchmal einige Zeit in Anspruch nimmt. 134 00:06:45,450 --> 00:06:48,330 ‫Eine andere Sache, die Sie hier vielleicht bemerken werden, 135 00:06:48,330 --> 00:06:50,690 ‫ist, dass dieser ID-Index, über den 136 00:06:50,690 --> 00:06:53,830 ‫wir zuvor gesprochen haben, hier eindeutig in Ordnung ist. 137 00:06:53,830 --> 00:06:56,030 ‫Und so einzigartig ist auch eine Eigenschaft, 138 00:06:56,030 --> 00:06:58,220 ‫die wir Indizes geben können. 139 00:06:58,220 --> 00:06:59,950 ‫Und das ist eigentlich der 140 00:06:59,950 --> 00:07:02,550 ‫Grund, warum die IDs immer eindeutig sein müssen. 141 00:07:02,550 --> 00:07:04,290 ‫Einfach deshalb, weil der 142 00:07:04,290 --> 00:07:07,180 ‫Index der ID diese eindeutige Eigenschaft hat. 143 00:07:07,180 --> 00:07:09,970 ‫Sie haben wahrscheinlich auch bemerkt, dass es hier einen Index 144 00:07:09,970 --> 00:07:11,760 ‫für den Namen gibt, oder? 145 00:07:11,760 --> 00:07:15,600 ‫Aber das haben wir nicht selbst manuell erstellt, oder? 146 00:07:15,600 --> 00:07:17,970 ‫Können Sie sich vorstellen, warum es hier ist? 147 00:07:17,970 --> 00:07:20,790 ‫Das liegt daran, dass wir in unserer Schemadefinition 148 00:07:20,790 --> 00:07:23,140 ‫das Namensfeld als eindeutig festgelegt haben. 149 00:07:23,140 --> 00:07:25,580 ‫Und was Mongos dann hinter 150 00:07:25,580 --> 00:07:28,900 ‫den Kulissen tut, um die Einzigartigkeit dieses Feldes 151 00:07:28,900 --> 00:07:32,170 ‫sicherzustellen, ist, einen eindeutigen Index dafür zu erstellen. 152 00:07:32,170 --> 00:07:34,630 ‫Aus diesem Grund muss nicht nur die 153 00:07:34,630 --> 00:07:37,410 ‫ID, sondern auch der Name immer eindeutig sein. 154 00:07:37,410 --> 00:07:40,520 ‫Okay und das ist schon toll. 155 00:07:40,520 --> 00:07:42,970 ‫Wenn wir also immer nur ein 156 00:07:42,970 --> 00:07:45,050 ‫einzelnes Feld abfragen, ist 157 00:07:45,050 --> 00:07:47,700 ‫ein einzelner Feldindex perfekt, denn denken Sie 158 00:07:47,700 --> 00:07:50,010 ‫daran, dass der Index, den 159 00:07:50,010 --> 00:07:53,200 ‫wir gerade festgelegt haben, als Einzelfeldindex bezeichnet wird. 160 00:07:53,200 --> 00:07:56,770 ‫Ich bin mir nicht sicher, ob ich es damals erwähnt habe, aber ich glaube, ich habe es getan. 161 00:07:56,770 --> 00:07:59,716 ‫Aber egal, wenn wir manchmal nach diesem Feld 162 00:07:59,716 --> 00:08:02,020 ‫fragen, aber mit einem anderen kombinieren, 163 00:08:02,020 --> 00:08:03,650 ‫dann ist es tatsächlich 164 00:08:03,650 --> 00:08:05,930 ‫effizienter, einen zusammengesetzten Index zu erstellen. 165 00:08:05,930 --> 00:08:09,210 ‫Also eines mit zwei Feldern und nicht nur einem. 166 00:08:09,210 --> 00:08:12,883 ‫Lassen Sie uns eine Abfrage dafür erstellen, nur um es zu veranschaulichen. 167 00:08:14,100 --> 00:08:16,000 ‫Ein weiteres Feld, das 168 00:08:16,000 --> 00:08:19,713 ‫meiner Meinung nach ständig abgefragt wird, ist der Bewertungsdurchschnitt. 169 00:08:22,470 --> 00:08:27,470 ‫Also durchschnittliche Bewertungen, ich denke, so wird es genannt, und sagen wir, wir 170 00:08:27,610 --> 00:08:32,610 ‫wollen größer oder gleich 4 sein. 7 okay. 171 00:08:35,370 --> 00:08:36,673 ‫Lassen Sie uns diese Anfrage senden. 172 00:08:38,230 --> 00:08:42,163 ‫Und mal sehen, wie viele Ergebnisse wir bekommen. 173 00:08:43,050 --> 00:08:44,440 ‫Wo ist das? 174 00:08:44,440 --> 00:08:45,400 ‫Ja hier. 175 00:08:45,400 --> 00:08:47,010 ‫Die Anzahl der Ergebnisse, 176 00:08:47,010 --> 00:08:49,290 ‫also die Anzahl der zurückgegebenen Dokumente, 177 00:08:49,290 --> 00:08:51,960 ‫die dieser Abfrage entsprechen, beträgt also zwei. 178 00:08:51,960 --> 00:08:55,390 ‫Aber wir mussten noch drei Dokumente prüfen. 179 00:08:55,390 --> 00:08:57,480 ‫Und das macht in dieser 180 00:08:57,480 --> 00:08:59,250 ‫Größenordnung natürlich keinen Unterschied. 181 00:08:59,250 --> 00:09:01,920 ‫Aber wie Sie verstehen, ist dies nur ein Beispiel. 182 00:09:01,920 --> 00:09:05,150 ‫Also wollen wir jetzt auch die Situation in Ordnung 183 00:09:05,150 --> 00:09:07,853 ‫bringen und verwenden dafür einen zusammengesetzten Index. 184 00:09:09,010 --> 00:09:10,870 ‫Gehen wir also hierher zurück. 185 00:09:10,870 --> 00:09:12,360 ‫Kommentieren Sie diesen aus. 186 00:09:12,360 --> 00:09:15,890 ‫Oder duplizieren Sie es zuerst und kommentieren Sie es dann. 187 00:09:15,890 --> 00:09:17,500 ‫Und so ist es eigentlich ganz einfach. 188 00:09:17,500 --> 00:09:20,103 ‫Alles, was wir tun müssen, ist, hier das andere Feld hinzuzufügen. 189 00:09:21,530 --> 00:09:25,270 ‫Die Bewertungen sind also durchschnittlich und ordnen wir diese in 190 00:09:25,270 --> 00:09:26,633 ‫aufsteigender Reihenfolge an. 191 00:09:29,150 --> 00:09:33,160 ‫Oder eigentlich ist das die absteigende Reihenfolge. 192 00:09:33,160 --> 00:09:35,290 ‫Lassen Sie uns das also speichern. 193 00:09:35,290 --> 00:09:37,060 ‫Gehen wir hierher zurück. 194 00:09:37,060 --> 00:09:41,720 ‫Und noch einmal, ich werde es hier ein paar Mal tun, okay. 195 00:09:41,720 --> 00:09:43,970 ‫Und sehen wir uns unsere Ergebnisse an. 196 00:09:43,970 --> 00:09:47,080 ‫Und so bekommen wir jetzt das gewünschte Ergebnis. 197 00:09:47,080 --> 00:09:49,880 ‫Es wurden also nur zwei Dokumente 198 00:09:49,880 --> 00:09:54,010 ‫gescannt, um die beiden eigentlich gesuchten Dokumente zu finden. 199 00:09:54,010 --> 00:09:57,420 ‫Perfekt und tatsächlich wird dieser zusammengesetzte Index, den wir 200 00:09:57,420 --> 00:10:00,700 ‫gerade erstellt haben, auch funktionieren, wenn die Abfrage 201 00:10:00,700 --> 00:10:04,020 ‫für nur eines dieser beiden Felder hier einzeln, also 202 00:10:04,020 --> 00:10:06,330 ‫Preis oder Bewertungen durchschnittlich ist. 203 00:10:06,330 --> 00:10:09,000 ‫Wenn wir also einen zusammengesetzten Index wie 204 00:10:09,000 --> 00:10:11,350 ‫diesen erstellen, müssen wir nicht 205 00:10:11,350 --> 00:10:14,193 ‫auch für jedes der Felder eine Person erstellen. 206 00:10:15,720 --> 00:10:19,603 ‫Ich möchte jetzt nur sehen, wie es in Compass aussieht. 207 00:10:21,310 --> 00:10:22,890 ‫Aber gut, es sieht immer noch gleich aus. 208 00:10:22,890 --> 00:10:25,320 ‫Aber auch hier nicht wirklich wichtig. 209 00:10:25,320 --> 00:10:27,440 ‫Eine Sache, die wir hier noch 210 00:10:27,440 --> 00:10:28,933 ‫sehen können und die 211 00:10:28,933 --> 00:10:31,663 ‫ziemlich interessant ist, ist die tatsächliche Größe dieser Indizes. 212 00:10:32,640 --> 00:10:36,680 ‫72 Kilobyte sind also tatsächlich viel größer als 213 00:10:36,680 --> 00:10:39,930 ‫die Gesamtgröße aller Dokumente zusammen, die 214 00:10:39,930 --> 00:10:42,680 ‫nur 14 Kilobyte beträgt, oder? 215 00:10:42,680 --> 00:10:45,470 ‫Im Grunde nehmen diese Indizes, die wir 216 00:10:45,470 --> 00:10:48,680 ‫zum Durchsuchen der Dokumente erstellen, viel mehr Platz 217 00:10:48,680 --> 00:10:50,890 ‫ein als die Dokumente selbst. 218 00:10:50,890 --> 00:10:53,530 ‫Aber auch das liegt daran, dass wir 219 00:10:53,530 --> 00:10:56,260 ‫in diesem Beispiel in einem so kleinen Maßstab operieren. 220 00:10:56,260 --> 00:10:59,300 ‫Und das ist nicht wirklich relevant, okay. 221 00:10:59,300 --> 00:11:01,530 ‫Aber es ist trotzdem wichtig, darüber 222 00:11:01,530 --> 00:11:05,150 ‫zu sprechen, denn das führt mich eigentlich zu unserer nächsten Frage. 223 00:11:05,150 --> 00:11:06,510 ‫Und diese Frage 224 00:11:06,510 --> 00:11:10,150 ‫ist, wie entscheiden wir, welches Feld wir tatsächlich indizieren müssen? 225 00:11:10,150 --> 00:11:13,710 ‫Und warum setzen wir nicht für alle Felder Indizes? 226 00:11:13,710 --> 00:11:16,720 ‫Nun, wir haben die Strategie verwendet, die ich verwendet 227 00:11:16,720 --> 00:11:20,640 ‫habe, um die Indizes auf den Preis und die durchschnittliche Bewertung festzulegen. 228 00:11:20,640 --> 00:11:24,380 ‫Im Grunde müssen wir also die Zugriffsmuster unserer Anwendung 229 00:11:24,380 --> 00:11:27,130 ‫sorgfältig studieren, um herauszufinden, welche Felder 230 00:11:27,130 --> 00:11:29,690 ‫am häufigsten abgefragt werden, und 231 00:11:29,690 --> 00:11:32,530 ‫dann die Indizes für diese Felder festlegen. 232 00:11:32,530 --> 00:11:36,640 ‫Zum Beispiel setze ich hier keinen Index für die Gruppengröße, weil ich 233 00:11:36,640 --> 00:11:38,060 ‫nicht wirklich glaube, 234 00:11:38,060 --> 00:11:41,300 ‫dass viele Leute nach diesem Parameter fragen werden, und 235 00:11:41,300 --> 00:11:43,890 ‫deshalb muss ich dort keinen Index erstellen. 236 00:11:43,890 --> 00:11:47,930 ‫Denn wir wollen es wirklich nicht mit Indizes übertreiben. 237 00:11:47,930 --> 00:11:51,610 ‫Wir wollen also nicht blindlings Indizes auf alle Felder setzen und 238 00:11:51,610 --> 00:11:54,110 ‫dann im Grunde das Beste hoffen. 239 00:11:54,110 --> 00:11:55,420 ‫Und der Grund 240 00:11:55,420 --> 00:11:58,380 ‫dafür ist, dass jeder Index tatsächlich Ressourcen 241 00:11:58,380 --> 00:12:01,360 ‫verbraucht, wie Sie hier richtig sehen können. 242 00:12:01,360 --> 00:12:04,850 ‫Außerdem muss jeder Index jedes Mal aktualisiert werden, wenn 243 00:12:04,850 --> 00:12:07,670 ‫die zugrunde liegende Sammlung aktualisiert wird. 244 00:12:07,670 --> 00:12:12,150 ‫Wenn Sie also eine Sammlung mit einem hohen Schreib-Lese-Verhältnis haben, also eine 245 00:12:12,150 --> 00:12:14,980 ‫Sammlung, in die hauptsächlich geschrieben wird, dann 246 00:12:14,980 --> 00:12:17,320 ‫wäre es absolut sinnlos, einen Index 247 00:12:17,320 --> 00:12:21,150 ‫für ein beliebiges Feld in dieser Sammlung zu erstellen, da 248 00:12:21,150 --> 00:12:23,800 ‫die Kosten für die ständige Aktualisierung des 249 00:12:23,800 --> 00:12:27,060 ‫Index und die Beibehaltung es im Speicher überwiegt eindeutig 250 00:12:27,060 --> 00:12:29,550 ‫den Vorteil, den Index überhaupt zu haben, 251 00:12:29,550 --> 00:12:31,750 ‫wenn wir selten Suchen 252 00:12:31,750 --> 00:12:34,240 ‫haben, also Abfragen für diese Sammlung. 253 00:12:34,240 --> 00:12:36,500 ‫Zusammenfassend müssen wir also bei der 254 00:12:36,500 --> 00:12:38,630 ‫Entscheidung, ob ein bestimmtes Feld indiziert 255 00:12:38,630 --> 00:12:40,750 ‫werden soll oder nicht, 256 00:12:40,750 --> 00:12:43,430 ‫die Häufigkeit von Abfragen, die genau dieses 257 00:12:43,430 --> 00:12:46,190 ‫Feld verwenden, mit den Kosten für die Pflege 258 00:12:46,190 --> 00:12:49,910 ‫dieses Index und auch mit dem Lese-Schreib-Muster der Ressource abwägen. 259 00:12:49,910 --> 00:12:52,950 ‫Doch genau wie bei der Datenmodellierung gibt es 260 00:12:52,950 --> 00:12:55,460 ‫hier keine wirklich harten Regeln. 261 00:12:55,460 --> 00:12:57,240 ‫Es ist also alles ein 262 00:12:57,240 --> 00:12:59,530 ‫bisschen unscharf und man braucht wirklich einige 263 00:12:59,530 --> 00:13:03,030 ‫Experimente und auch Erfahrung, um es richtig zu machen, in Ordnung. 264 00:13:03,030 --> 00:13:06,570 ‫Aber was auch immer Sie tun, ignorieren Sie bitte nicht die Indizierung. 265 00:13:06,570 --> 00:13:08,550 ‫Denn auch wenn es nicht 266 00:13:08,550 --> 00:13:12,660 ‫perfekt ist, hat es immer einen großen Nutzen für Ihre Anwendung. 267 00:13:12,660 --> 00:13:14,940 ‫In Ordnung, und das ist eigentlich alles, was ich 268 00:13:14,940 --> 00:13:16,903 ‫Ihnen über Indizes zu sagen hatte. 269 00:13:18,230 --> 00:13:21,880 ‫Es gibt nur noch einen Index, den ich hier eigentlich einstellen 270 00:13:21,880 --> 00:13:25,030 ‫möchte, der für die Tour-Schnecke in Ordnung ist. 271 00:13:25,030 --> 00:13:26,920 ‫Denn später werden wir eigentlich 272 00:13:26,920 --> 00:13:30,250 ‫die Unique Slug verwenden wollen, um nach Touren abzufragen. 273 00:13:30,250 --> 00:13:32,680 ‫Das bedeutet, dass die Schnecke dann wahrscheinlich das 274 00:13:32,680 --> 00:13:34,640 ‫am meisten abgefragte Feld wird. 275 00:13:34,640 --> 00:13:35,950 ‫Es macht also 276 00:13:35,950 --> 00:13:38,780 ‫Sinn, auch dafür einen Index zu haben. 277 00:13:38,780 --> 00:13:41,460 ‫Also Tourschema. Index 278 00:13:45,370 --> 00:13:47,380 ‫und Schnecke eins. 279 00:13:47,380 --> 00:13:52,140 ‫Und meistens ist das Eins oder das Minus nicht so wichtig. 280 00:13:52,140 --> 00:13:54,680 ‫Okay, jetzt bin ich wirklich neugierig, dies 281 00:13:54,680 --> 00:13:56,640 ‫hier in Compass zu sehen. 282 00:13:56,640 --> 00:14:00,500 ‫Ich werde also versuchen, hier erneut eine Verbindung 283 00:14:00,500 --> 00:14:02,043 ‫zur Datenbank herzustellen. 284 00:14:06,740 --> 00:14:10,083 ‫Und so kann ich das hier nur aus den neuesten herausholen. 285 00:14:11,360 --> 00:14:14,020 ‫Klicken Sie auf, verbinden Sie sich, und dann sollten wir 286 00:14:14,020 --> 00:14:15,453 ‫mit derselben Datenbank verbunden werden. 287 00:14:17,260 --> 00:14:21,540 ‫Also Natours, Tours, kommen wir zu unseren Verzeichnissen. 288 00:14:21,540 --> 00:14:23,380 ‫Und jetzt geht es los. 289 00:14:23,380 --> 00:14:26,013 ‫Jetzt haben wir also unsere Indizes genau hier. 290 00:14:27,070 --> 00:14:28,920 ‫Vergrößern wir dieses Fenster und 291 00:14:28,920 --> 00:14:31,290 ‫schauen wir uns an, was wir bekommen haben. 292 00:14:31,290 --> 00:14:33,710 ‫Wir haben also unsere Schnecke hier. 293 00:14:33,710 --> 00:14:36,670 ‫Wir haben den Preis, den wir zuerst festlegen. 294 00:14:36,670 --> 00:14:39,940 ‫Und dann haben wir auch den Preis- und Bewertungsdurchschnitt, 295 00:14:39,940 --> 00:14:42,610 ‫der zusammengesetzt ist, und Sie sehen hier auch, 296 00:14:42,610 --> 00:14:45,510 ‫dass dieser hier aufsteigend ist und dieser absteigend, 297 00:14:45,510 --> 00:14:47,740 ‫weil er das Minus hat. 298 00:14:47,740 --> 00:14:49,870 ‫Und was Ihnen vielleicht auffällt, ist, 299 00:14:49,870 --> 00:14:50,880 ‫dass wir 300 00:14:50,880 --> 00:14:53,680 ‫diesen Preisindex tatsächlich nicht mehr in unserem Code haben. 301 00:14:53,680 --> 00:14:55,070 ‫Aber es ist noch da. 302 00:14:55,070 --> 00:14:58,630 ‫Es reicht also nicht aus, den Index aus 303 00:14:58,630 --> 00:15:03,430 ‫unserem Code zu entfernen, wir müssen ihn wirklich aus der Datenbank selbst löschen. 304 00:15:03,430 --> 00:15:05,870 ‫Denken Sie also daran, dass wir ihn am 305 00:15:05,870 --> 00:15:07,460 ‫Anfang hier hatten und 306 00:15:07,460 --> 00:15:09,780 ‫dann auskommentiert und diesen neuen zusammengesetzten Index erstellt 307 00:15:09,780 --> 00:15:12,300 ‫haben, aber auch hier steht der Index still. 308 00:15:12,300 --> 00:15:14,430 ‫Aber da wir es 309 00:15:14,430 --> 00:15:18,170 ‫eigentlich nicht mehr brauchen, können wir es einfach löschen. 310 00:15:18,170 --> 00:15:21,070 ‫Jetzt müssen wir den Namen nur noch eingeben, um 311 00:15:21,070 --> 00:15:23,413 ‫sicherzustellen, dass wir keine Fehler machen. 312 00:15:25,110 --> 00:15:27,410 ‫Also los geht's, großartig. 313 00:15:27,410 --> 00:15:30,050 ‫Das ist also die Macht der Indizes. 314 00:15:30,050 --> 00:15:32,420 ‫Sie können unsere Leseleistung in 315 00:15:32,420 --> 00:15:34,970 ‫Datenbanken wirklich viel, viel besser machen. 316 00:15:34,970 --> 00:15:36,700 ‫In Ihren eigenen 317 00:15:36,700 --> 00:15:39,460 ‫Anwendungen sollten Sie diese also niemals ignorieren. 318 00:15:39,460 --> 00:15:42,680 ‫Und bevor wir fertig sind, nehmen wir noch 319 00:15:42,680 --> 00:15:45,140 ‫die EXPLAIN-Methode zurück, die wir 320 00:15:45,140 --> 00:15:47,860 ‫hier in unserer Handler-Funktion hinzugefügt haben. 321 00:15:47,860 --> 00:15:49,430 ‫Und eigentlich nur 322 00:15:49,430 --> 00:15:52,283 ‫als Referenz, ich werde es hier so belassen. 323 00:15:54,640 --> 00:15:55,543 ‫Sparen Sie. 324 00:15:57,090 --> 00:15:58,133 ‫Zurück im Post-Menü. 325 00:15:59,280 --> 00:16:00,773 ‫Versuchen wir das jetzt. 326 00:16:01,670 --> 00:16:04,040 ‫Und tatsächlich, es funktioniert wieder. 327 00:16:04,040 --> 00:16:05,763 ‫Okay und jetzt ist es wirklich so.