Ich bin mir nicht sicher, ob MapReduce das Problem löst, aber es wäre sicherlich nicht MapReduce allein, um all diese Fragen zu lösen, die Sie aufgeworfen haben. Hier sind jedoch wichtige Dinge zu beachten, die es möglich machen, bei Abfragen von all diesen TBs von Daten auf verschiedenen Computern eine so geringe Latenz zu haben:
- Verteiltes Rechnen: Verteilt zu sein bedeutet nicht, dass die Indizes einfach auf verschiedenen Computern verteilt werden. Sie werden tatsächlich entlang verschiedener Cluster repliziert, was es vielen Benutzern ermöglicht, unterschiedliche Abfragen mit geringer Abrufzeit durchzuführen (ja, große Unternehmen können sich das leisten von Maschinen);
- Caching: Caches reduzieren die Ausführungszeit erheblich, sei es für den Crawling-Schritt, für das Abrufen von Seiten oder für das Ranking und die Ausstellung von Ergebnissen.
- Viele Optimierungen: Alle oben genannten und sehr effizienten Algorithmen / Lösungen können nur dann effektiv sein, wenn die Implementierung auch effizient ist. Es gibt unzählige (fest codierte) Optimierungen, z. B. Referenzort, Komprimierung, Caching. Alle von ihnen sind normalerweise auf verschiedene Teile der Verarbeitung anwendbar.
In Anbetracht dessen versuchen wir, Ihre Fragen zu beantworten:
Ich halte es jedoch für unmöglich, die Ergebnisse jeder einzelnen möglichen Abfrage zu indizieren
Ja, es wäre und tatsächlich unmöglich, Ergebnisse für jede einzelne mögliche Abfrage zu haben . Es gibt unendlich viele Begriffe auf der Welt (selbst wenn Sie davon ausgehen, dass nur richtig geschriebene Begriffe eingegeben werden), und es gibt eine exponentielle Anzahl von Abfragen aus diesen n -> infBegriffen ( 2^n). Was wird also gemacht? Caching. Aber wenn es so viele Abfragen / Ergebnisse gibt, welche müssen zwischengespeichert werden? Caching-Richtlinien. Die häufigsten / beliebtesten / für den Benutzer relevanten Abfragen sind die zwischengespeicherten.
Wäre die Hardwarelatenz in Googles Hardware nicht riesig? Auch wenn die Daten in Google alle in TB / s-SSDs gespeichert waren
Heutzutage denken die Leute bei solch hoch entwickelten Prozessoren, dass jede mögliche Aufgabe, die innerhalb einer Sekunde (oder weniger) erledigt werden muss und die so viele Daten verarbeitet, von extrem leistungsstarken Prozessoren mit mehreren Kernen und viel Speicher verarbeitet werden muss. Allerdings ist die eine Sache herrschenden ist Markt Geld, und die Investoren sind in verschwenden sie nicht interessiert. Was wird also gemacht?
Die Präferenz besteht tatsächlich darin, viele Maschinen zu haben, die jeweils einfache / zugängliche (in Bezug auf die Kosten) Prozessoren verwenden, was den Preis für den Aufbau der Vielzahl der vorhandenen Cluster senkt. Und ja, es funktioniert. Der Hauptengpass läuft immer auf die Festplatte hinaus, wenn Sie einfache Leistungsmessungen in Betracht ziehen . Aber wenn es so viele Maschinen gibt, kann man es sich leisten, Dinge in den Hauptspeicher zu laden, anstatt auf Festplatten zu arbeiten.
Speicherkarten sind für uns, bloße Menschen, teuer , aber für Unternehmen, die viele solcher Karten gleichzeitig kaufen, sehr billig. Da es nicht teuer ist, ist es kein Problem, bei Bedarf über viel Speicher zu verfügen, um Indizes zu laden und Caches zur Hand zu haben. Und da es so viele Maschinen gibt, sind keine superschnellen Prozessoren erforderlich, da Sie Anfragen an verschiedene Orte richten können und Gruppen von Maschinen für die Bearbeitung bestimmter geografischer Regionen zuständig sind , was ein spezialisierteres Daten-Caching und eine noch bessere Reaktion ermöglicht mal.
Hilft MapReduce bei der Lösung dieses Problems?
Obwohl ich nicht denke, dass die Verwendung oder Nichtverwendung von MapReduce Informationen in Google einschränkt, bin ich mit diesem Punkt nicht vertraut. Die Implementierung von MapReduce durch Google (was sicherlich nicht Hadoop ist) muss jedoch viele Optimierungen aufweisen, von denen viele die oben diskutierten Aspekte betreffen. Die Architektur von MapReduce hilft wahrscheinlich dabei, die physische Verteilung der Berechnungen zu bestimmen. Es sind jedoch noch viele andere Punkte zu berücksichtigen, um eine solche Geschwindigkeit bei der Abfragezeit zu rechtfertigen.
Okay, ich verstehe, dass beliebte Suchanfragen im Speicher zwischengespeichert werden können. Aber was ist mit unpopulären Suchanfragen?
Die folgende Grafik zeigt eine Kurve, wie die Arten von Abfragen auftreten. Sie können sehen, dass es drei Hauptarten von Suchvorgängen gibt, von denen jede ungefähr 1/3 des Abfragevolumens enthält (Bereich unter der Kurve). Die Handlung zeigt das Potenzgesetz und verstärkt die Tatsache, dass kleinere Abfragen am beliebtesten sind. Das zweite Drittel der Abfragen kann noch bearbeitet werden, da sie nur wenige Wörter enthalten. Die Menge der sogenannten obskuren Abfragen , die normalerweise aus nicht erfahrenen Benutzerabfragen bestehen, ist jedoch kein vernachlässigbarer Teil der Abfragen.
Und es gibt Raum für neuartige Lösungen. Da es sich nicht nur um eine oder zwei Abfragen handelt (sondern um ein Drittel davon), müssen sie relevante Ergebnisse haben. Wenn Sie in einer Google-Suche etwas viel zu Dunkles eingeben, dauert es nicht länger, eine Ergebnisliste zurückzugeben, sondern zeigt Ihnen höchstwahrscheinlich etwas an, auf das Sie schließen möchten. Oder es kann einfach angegeben werden, dass es kein Dokument mit solchen Begriffen gab - oder sogar Ihre Suche auf 32 Wörter reduzieren (was mir gerade in einem zufälligen Test hier passiert ist).
Es gibt Dutzende anwendbarer Heuristiken, die entweder darin bestehen, einige Wörter zu ignorieren oder zu versuchen, die Abfrage in kleinere zu unterteilen und die beliebtesten Ergebnisse zu erzielen . Und all diese Lösungen können so angepasst und optimiert werden, dass mögliche Wartezeiten von beispielsweise weniger als einer Sekunde eingehalten werden. : D.