Aus der höflichen Interpretation von „NoSQL“ wurde Not Only SQL . Wenn Sie Daten haben, die tatsächlich relational sind, oder wenn Ihre Funktionalität von Dingen wie Joins und ACIDity abhängt, sollten Sie diese Daten relational speichern. In diesem Beitrag erkläre ich, wie ich MySQL zusammen mit zwei verwende NoSQL-Datenspeicher. Bei moderner, webbasierter Datenspeicherung geht es darum, zu verstehen, wie man das/die beste(n) Tool(s) für die Aufgabe(n) auswählt.
Das heißt, NoSQL ist wirklich eine Reaktion auf die Tatsache, dass die relationale Methode und Denkweise auf Probleme angewendet wurde, bei denen sie eigentlich nicht sehr gut passt (typischerweise riesige Tabellen mit mehreren zehn Millionen Zeilen oder mehr). Sobald Tabellen so groß werden, bestand die typische „Best Practice“ für SQL darin, manuell zu sharden die Daten – das heißt, die Datensätze 1 bis 10.000.000 in Tabelle A, 10.000.001 bis 20.000.001 in Tabelle B und so weiter. Dann werden typischerweise in der Anwendungsmodellschicht die Lookups gemäß diesem Schema durchgeführt. Das nennt man application-aware Skalierung. Es ist zeitintensiv und fehleranfällig, aber um etwas zu skalieren und gleichzeitig MySQL für den Long-Table-Speicher zu verwalten, ist es zu einem mehr oder weniger Standard-MO geworden. NoSQL repräsentiert für mich die application-unaware Alternative.
Schlüsselwert
Als mir ein MySQL-Prototyp zu groß wurde, verschob ich persönlich so viele Daten wie möglich auf die blitzschnelle Membase , das Memcached übertrifft und Persistenz hinzufügt. Membase ist ein verteilter Schlüsselwertspeicher, der mehr oder weniger linear skaliert (Zynga verwendet ihn zum Beispiel, um eine halbe Million Operationen pro Sekunde zu verarbeiten), indem mehr Commodity-Server zu einem Cluster hinzugefügt werden – es ist daher ein großartiger fit für das Cloud-Zeitalter von Amazon EC2 , Joyent usw.
Es ist allgemein bekannt, dass verteilte Key-Value-Speicher der beste Weg sind, um eine enorme, lineare Skalierung zu erreichen. Die Schwäche von Schlüsselwerten ist die Abfragebarkeit und Indizierung. Aber selbst in der relationalen Welt besteht die beste Vorgehensweise für die Skalierbarkeit darin, so viel Aufwand wie möglich auf die Anwendungsserver zu verlagern und Verknüpfungen im Speicher auf handelsüblichen App-Servern durchzuführen, anstatt den zentralen RDB-Cluster zu bitten, die gesamte Logik zu handhaben. Da simple select plus application logic sind wirklich der beste Weg, um sogar auf eine massive Skalierung zu erreichen MySQL, der Übergang zu etwas wie Membase (oder seinen Konkurrenten wie Riak
). ) ist nicht wirklich schlecht.
Dokumentspeicher
Manchmal – obwohl ich seltener argumentieren würde, als viele denken – erfordert das Design einer Anwendung von Natur aus sekundäre Indizes, Bereichsabfrage usw. Der NoSQL-Ansatz dafür ist ein document store wie MongoDB
. Wie Membase ist Mongo in einigen Bereichen sehr gut, in denen relationale Datenbanken besonders schwach sind, wie z. B. application-unaware Skalierung, auto-sharding , und maintaining flat response times even as dataset size balloons . Es ist erheblich langsamer als Membase und etwas schwieriger, eine reine horizontale Skalierung durchzuführen, aber der Vorteil ist, dass es sehr abfragbar ist. Sie können Parameter und Bereiche in Echtzeit abfragen, oder Sie können Map/Reduce verwenden, um komplexe Batch-Operationen an wirklich riesigen Datensätzen durchzuführen.
Bei demselben Projekt, das ich oben erwähnt habe und das Membase verwendet, um Tonnen von Live-Spielerdaten bereitzustellen, verwenden wir MongoDB, um Analyse-/Metrikdaten zu speichern, wo MongoDB wirklich glänzt.
Warum Dinge in SQL behalten
Ich habe kurz die Tatsache angesprochen, dass „wirklich relationale“ Informationen in relationalen Datenbanken bleiben sollten. Wie der Kommentator Dan K. betont, habe ich den Teil verpasst, in dem ich die Nachteile des Verlassens von RDBMS oder zumindest des vollständigen Verlassens bespreche.
Zuerst gibt es SQL selbst. SQL ist bekannt und seit langem Industriestandard. Einige "NoSQL"-Datenbanken wie Googles App Engine
Datastore (basierend auf Big Table) implementieren ihre eigene SQL-ähnliche Sprache (die von Google heißt netterweise GQL für Google Query Language). ). MongoDB verfolgt mit seinen reizvollen JSON-Abfrageobjekten
einen neuen Ansatz für das Abfrageproblem . Dennoch ist SQL selbst ein mächtiges Werkzeug, um Informationen aus Daten zu gewinnen, was oft der eigentliche Sinn von Datenbanken ist, um damit anzufangen.
Der wichtigste Grund, bei RDBMS zu bleiben, ist ACID
, oder Atomicity, Consistency, Isolation, Durability . Ich werde den Status von Acid-NoSQL nicht erneut hashen, da er in dieser Beitrag
auf SO. Es genügt zu sagen, dass es einen vernünftigen Grund gibt Oracles RDBMS
hat einen so riesigen Markt, der nirgendwohin führt:Einige Daten erfordern eine reine ACID-Konformität . Wenn Ihre Daten das tun (und wenn ja, sind Sie sich dessen wahrscheinlich bewusst), dann auch Ihre Datenbank. Behalten Sie diesen pH
bei niedrig!
Bearbeiten: Sehen Sie sich den Beitrag von Aaronaught hier an Er vertritt die Business-to-Business-Perspektive viel besser als ich es könnte, zum Teil, weil ich meine gesamte Karriere im Verbraucherbereich verbracht habe.
