Ich habe einmal mit einer sehr großen (Terabyte+) MySQL-Datenbank gearbeitet. Die größte Tabelle, die wir hatten, hatte buchstäblich über eine Milliarde Zeilen.
Es funktionierte. MySQL verarbeitete die Daten die meiste Zeit korrekt. Es war allerdings sehr unhandlich.
Allein das Sichern und Speichern der Daten war eine Herausforderung. Es würde Tage dauern, die Tabelle wiederherzustellen, wenn es nötig wäre.
Wir hatten zahlreiche Tabellen im Bereich von 10 bis 100 Millionen Reihen. Alle signifikanten Verknüpfungen mit den Tabellen waren zu zeitaufwändig und würden ewig dauern. Also haben wir gespeicherte Prozeduren geschrieben, um die Tabellen zu „laufen“ und Joins gegen Bereiche von „IDs“ zu verarbeiten. Auf diese Weise würden wir die Daten 10-100.000 Zeilen gleichzeitig verarbeiten (Join gegen IDs 1-100.000, dann 100.001-200.000 usw.). Das war deutlich schneller als gegen den gesamten Tisch anzutreten.
Die Verwendung von Indizes für sehr große Tabellen, die nicht auf dem Primärschlüssel basieren, ist ebenfalls viel schwieriger. MySQL speichert Indizes in zwei Teilen – es speichert Indizes (außer dem Primärindex) als Indizes für die Primärschlüsselwerte. Indizierte Suchen werden also in zwei Teilen durchgeführt:Zuerst geht MySQL zu einem Index und zieht daraus die Primärschlüsselwerte, die es finden muss, dann führt es eine zweite Suche im Primärschlüsselindex durch, um herauszufinden, wo sich diese Werte befinden.
Das Netto davon ist, dass für sehr große Tabellen (mehr als 1-200 Millionen Zeilen) die Indizierung von Tabellen restriktiver ist. Sie benötigen weniger, einfachere Indizes. Und selbst einfache Select-Anweisungen, die sich nicht direkt auf einem Index befinden, werden möglicherweise nie wieder ausgeführt. Wo Klauseln müssen Schlagen Sie Indizes oder vergessen Sie es.
Aber trotz alledem funktionierten die Dinge tatsächlich. Wir konnten MySQL mit diesen sehr großen Tabellen verwenden und Berechnungen durchführen und richtige Antworten erhalten.
