it-swarm.com.de

Gibt es für RMSMS für strukturierte Daten auf einer Maschine echte Vorteile gegenüber NoSQL?

Daher habe ich mich sehr bemüht herauszufinden, ob NoSQL so viel Wert außerhalb des Auto-Sharding und der Handhabung von UNSTRUCTURED-Daten bietet.

Angenommen, ich kann meine STRUCTURED-Daten auf einem einzelnen Computer speichern OR und eine effektive Auto-Sharding-Funktion für SQL verwenden. Welche Vorteile bieten NoSQL-Optionen? Ich habe folgendes festgestellt:

  1. Dokumentbasiert (MongoDB, Couchbase usw.) - Abgesehen von den "Auto-Sharding" -Funktionen kann ich nur schwer verstehen, wo der Vorteil liegt. Verknüpfte Objekte sind SQL-Joins sehr ähnlich, während eingebettete Objekte die Dokumentgröße erheblich aufblähen und eine Herausforderung hinsichtlich der Replikation verursachen (ein Kommentar könnte sowohl zu einem Post-Eintrag als auch zu einem Benutzer gehören und die Daten wären daher redundant). Auch der Verlust von ACID und Transaktionen ist ein großer Nachteil.

  2. Schlüsselwertbasiert (Redis, Memcached usw.) - Dient einem anderen Anwendungsfall, ideal zum Zwischenspeichern, jedoch nicht für komplexe Abfragen

  3. Kolumnar (Cassandra, HBase, etc) - Der große Vorteil hier ist eher die Art und Weise, wie die Daten auf der Festplatte gespeichert werden, und ist meistens eher für Aggregationen als für den allgemeinen Gebrauch nützlich

  4. Grafik (Neo4j, OrientDB usw.) - Die interessanteste Verwendung von Kanten und Knoten ergibt eine interessante Wertevorsicht, die jedoch meist eher für sehr komplexe relationale Daten als für die allgemeine Verwendung nützlich ist.

Ich kann die Vorteile von Schlüsselwert-, Spalten- und Diagramm-DBs für bestimmte Anwendungsfälle erkennen (Caching, Zuordnung von Beziehungsnetzwerken zu sozialen Netzwerken, Aggregationen), aber ich sehe keinen Grund, etwas wie MongoDB für STRUCTURED-Daten außerhalb seiner 'auto- Sharding-Fähigkeiten. 

Wenn SQL über eine ähnliche Fähigkeit zum automatischen Sharding verfügt, wäre SQL für strukturierte Daten ein Kinderspiel? Scheint mir so, aber ich hätte gerne die Meinung der Community ...

HINWEIS: Dies bezieht sich auf eine typische CRUD-Anwendung wie ein soziales Netzwerk, eine E-Commerce-Site, ein CMS usw.

27
jessedrelick

Wenn Sie auf einem einzelnen Server starten, gehen viele Vorteile von NoSQL aus dem Fenster. Die größten Vorteile gegenüber dem beliebtesten NoSQL sind die hohe Verfügbarkeit bei geringeren Ausfallzeiten. Eventuelle Konsistenzanforderungen können ebenfalls zu Leistungsverbesserungen führen. Es hängt wirklich von Ihren Bedürfnissen ab.

  1. Dokumentbasiert - Wenn Ihre Daten gut in eine Handvoll kleiner Datenmengen passen, dann eine dokumentenorientierte Datenbank. Zum Beispiel haben wir auf einer Kleinanzeigen-Site Benutzer, Konten und Einträge als Kerndaten. Der Großteil der Such- und Anzeigeoperationen erfolgt ausschließlich gegen die Listings. Mit der alten Datenbank müssen wir fast 40 Verknüpfungsvorgänge ausführen, um die Daten für eine einzelne Auflistung abzurufen. Bei NoSQL handelt es sich um eine einzelne Abfrage. Mit NoSQL können wir auch Indizes für verschachtelte Daten erstellen, wobei die Ergebnisse auch ohne Joins abgefragt werden. In diesem Fall spiegeln wir Daten aus SQL in MongoDB, um sie zu suchen und anzuzeigen (es gibt andere Gründe). Derzeit wird an einer längerfristigen Migrationsstrategie gearbeitet. ElasticSearch, RethinkDB und andere sind ebenfalls großartige Datenbanken. RethinkDB geht die Daten tatsächlich sehr konservativ an, und die Standardindizierung von ElasticSearch ist unübertroffen.

  2. Schlüsselwertspeicher - Caching ist hier ein ausgezeichneter Anwendungsfall, wenn Sie eine Website mit mittlerem bis hohem Volumen betreiben, auf der die meisten Daten gelesen werden, ein gutes Caching Mit einer Strategie allein können Sie das 4-5-fache der Benutzer erreichen, die von einem einzelnen Server verwaltet werden. Schlüsselwertspeicher (RocksDB, LevelDB, Redis usw.) sind ebenfalls sehr gute Optionen für Diagrammdaten, da einzelne Zuordnungen mit Subjekt-Prädikat-Zielwerten gespeichert werden können, die für grafische Darstellungsoptionen sehr schnell sind.

  3. Columnar - Cassandra kann insbesondere verwendet werden, um signifikante Mengen an Last für sogar Einzelwert-Lookups zu verteilen. Cassandras Skalierung ist sehr linear zur Anzahl der verwendeten Server. Ideal für umfangreiche Lese- und Schreibszenarien. Ich finde das weniger wertvoll für Live-Suchen, aber sehr gut, wenn Sie ein [~ # ~] sehr [~ # ~] haben. hohe last und verteilen müssen. Es erfordert viel mehr Planung und entspricht möglicherweise nicht Ihren Anforderungen. Sie können die Einstellungen an Ihre CAP-Anforderungen anpassen und sogar die Verteilung auf mehrere Rechenzentren in der Box verwalten. HINWEIS: Die meisten Anwendungen benötigen diese Nutzungsstufe nachdrücklich [~ # ~] nicht [~ # ~]. ElasticSearch passt möglicherweise besser in die meisten Szenarien, in denen Sie HBase/Hadoop oder Cassandra for.

  4. Graph - Ich bin mit Graphendatenbanken nicht so vertraut und kann daher hier keine Kommentare abgeben (abgesehen von der Verwendung eines Schlüsselwertspeichers als zugrunde liegende Option).

Vorausgesetzt, Sie kommentieren dann speziell MongoDB vs SQL ... auch wenn beide Auto-Shard. Insbesondere PostgreSQL hat viele Fortschritte in Bezug auf die Nutzung uneingeschränkter Daten gemacht (JSON/JSONB-Typen), ganz zu schweigen von der Leistung, die Sie mit PLV8 erzielen können. Es ist wahrscheinlich am besten geeignet, um mit den Arten von Lasten umzugehen, auf die Sie möglicherweise werfen ein Dokumentenspeicher mit den Vorteilen von NoSQL. Es kann passieren, dass Replikation, Sharding und Failover auf Lösungen basieren, die nicht im Lieferumfang enthalten sind.

Für kleine bis mittlere Lasten ist Splittern nicht der beste Ansatz. Die meisten Szenarien werden meistens gelesen, daher ist ein Replikatsatz mit zusätzlichen Leseknoten in der Regel besser, wenn Sie über 3-5 Server verfügen. MongoDB ist in diesem Szenario großartig, der Masterknoten wird automatisch ausgewählt und das Failover ist ziemlich schnell. Die einzige Verrücktheit, die ich gesehen habe, ist, dass Azure Ende 2014 ausfiel und nur einer der Server als erster hochgefahren wurde, die anderen beiden fast 40 Minuten später. Bei der Replikation kann eine Leseanforderung vollständig von einem einzelnen Server verarbeitet werden. Ihre Datenstrukturen werden einfacher und das Risiko von Datenverlusten wird verringert.

Wieder in meinem Beispiel oben, für eine mittelgroße Kleinanzeigen-Site gehört die überwiegende Mehrheit der Daten zu einer einzelnen Sammlung ... sie werden durchsucht und aus dieser Sammlung angezeigt. Mit diesem Anwendungsfall funktioniert ein Dokumentenspeicher viel besser als strukturierte/normalisierte Daten. Die Art und Weise, wie die Objekte gespeichert werden, kommt ihrer Darstellung in der Anwendung sehr viel näher. Es gibt weniger kognitive Unterbrechungen und es funktioniert einfach.

Tatsache ist, dass SQL JOIN-Vorgänge die Leistung beeinträchtigen, insbesondere wenn Daten über diese Verknüpfungen hinweg aggregiert werden. Für eine einzelne Abfrage für einen einzelnen Benutzer ist es in Ordnung, auch mit einem Dutzend von ihnen. Wenn Sie Dutzende von Joins mit Tausenden von gleichzeitigen Benutzern erreichen, beginnt es auseinanderzufallen. An dieser Stelle haben Sie mehrere Möglichkeiten ...

  • Caching - Caching ist immer ein guter Ansatz. Je seltener sich Ihre Daten ändern, desto besser ist der Ansatz. Dies kann alles sein, von einer Reihe von memcache/redis-Instanzen bis hin zur Verwendung von MongoDB, RethinkDB oder ElasticSearch, um zusammengesetzte Datensätze zu speichern. Die Herausforderung besteht darin, Ihre zwischengespeicherten Daten zu aktualisieren oder ungültig zu machen.

  • Migration - Eine Migration Ihrer Daten in einen Datenspeicher, der Ihre Anforderungen besser repräsentiert, kann ebenfalls eine gute Idee sein. Wenn Sie mit massiven Schreibvorgängen oder sehr massiven Leseszenarien umgehen müssen, kann keine SQL-Datenbank mithalten. Sie könnten [~ # ~] nie [~ # ~] mit Facebook oder Twitter auf SQL umgehen.

  • Etwas dazwischen - Wie Sie skalieren müssen, hängt davon ab, was Sie tun und wo Ihre Schmerzpunkte liegen, um die beste Lösung für ein Problem zu finden gegebene Situation. Viele Entwickler und Administratoren befürchten, dass Daten an mehreren Stellen aufgeteilt werden. Dies ist jedoch häufig die beste Antwort. Müssen sich Ihre Analysedaten wirklich an der gleichen Stelle befinden wie Ihre Kernbetriebsdaten? Müssen Ihre Logins eng miteinander verbunden sein? Machst du viele korrelierte Abfragen? Es kommt wirklich darauf an.


Persönliche Meinungen voraus

Mir gefällt das Sicherheitsnetz, das SQL bietet. Als zentraler Speicher für Kerndaten ist es meine erste Wahl. Ich neige dazu, RDBMS als dummen Speicher zu behandeln. Ich bin nicht gerne an eine bestimmte Plattform gebunden. Ich habe das Gefühl, dass viele Leute versuchen, ihre Daten zu stark zu normalisieren. Oft füge ich einer Tabelle ein XML- oder JSON-Feld hinzu, damit zusätzliche Daten gespeichert werden können, ohne dass das Schema aufgebläht wird. Dies gilt insbesondere dann, wenn es unwahrscheinlich ist, dass sie jemals abgefragt werden. Dann habe ich Eigenschaften in meinen Objekten im Anwendungscode, die in diesen Feldern speichern. Ein gutes Beispiel kann eine Zahlung sein ... Wenn Sie derzeit ein System oder mehrere Systeme (eines für CC zusammen mit Paypal, Google, Amazon usw.) verwenden, haben die Details der Transaktion keinen Einfluss auf Ihre Unterlagen. Warum erstellen? 5+ Tabellen zum Speichern dieser detaillierten Daten. Sie können JSON sogar für den Primärspeicher verwenden und Spalten aus diesem JSON ableiten und beibehalten lassen, um die Abfragefunktionen zu erweitern und bei Bedarf zu indizieren. Datenbanken wie postgresql und mysql (iirc) bieten auch eine direkte Indizierung für JSON-Daten.

Wenn Daten für einen Dokumentenspeicher geeignet sind, kann ich sagen, dass Sie sich dafür entscheiden ... Wenn die große Mehrheit Ihrer Abfragen für etwas bestimmt ist, das für einen einzelnen Datensatz oder eine einzelne Sammlung besser geeignet ist, denormalisieren Sie diese. Es ist großartig, dies als Spiegel für Ihre Primärdaten zu haben.

Für schreiblastige Daten möchten Sie mehrere Systeme im Spiel haben. Dies hängt stark von Ihren Anforderungen ab. Benötigen Sie eine schnelle Hot-Query-Leistung? Gehen Sie mit ElasticSearch. Benötigen Sie eine absolut massive horizontale Skala, HBase oder Cassandra?.

Der Schlüssel zum Mitnehmen ist, keine Angst zu haben, es zu verwechseln ... es gibt wirklich keine Einheitsgröße. Abgesehen davon bin ich der Meinung, dass PostgreSQL, wenn es sich um eine sofort einsatzbereite (für die Open-Source-Version) Lösung handelt, auch wenn es sich nur um Replikation und automatisiertes Failover handelt, zu diesem Zeitpunkt in einer viel besseren Position als die meisten anderen.

Ich bin nicht wirklich darauf eingegangen, aber ich sollte erwähnen, dass es eine Reihe von SaaS) - Lösungen und andere Anbieter gibt, die hybride SQL-Systeme anbieten. Sie können lokal gegen MySQL/MariaDB entwickeln und auf bereitstellen Ein System mit SQL auf einem verteilten Speichercluster Ich bin immer noch der Meinung, dass HBase oder ElasticSearch besser für die Protokollierung und Analyse von Daten geeignet sind, aber auch die SQL-On-Top-Lösungen überzeugen.

Mehr: http://www.mongodb.com/nosql-explained

23
Tracker1

Speicher ohne Schema (oder schemafrei). Möglichkeit, den Speicher zu ändern (im Wesentlichen neue Felder zu Datensätzen hinzuzufügen), ohne das "deklarierte" Schema des Speichers ändern zu müssen. RDBMSs erfordern die explizite Deklaration der "Felder" und erfordern explizite Änderungen am Schema, bevor ein neues "Feld" gespeichert wird. Eine schemafreie Speicher-Engine ermöglicht schnelle Anwendungsänderungen. Sie müssen lediglich den App-Code ändern, um die zusätzlichen Felder zu speichern, die Felder umbenennen oder Felder löschen und fertig.

Traditionelle RDBMS-Leute halten den schemafreien a Nachteil für, weil sie argumentieren, dass man langfristig den Speicher abfragen und die heterogenen Datensätze behandeln muss (einige haben einige Felder, andere haben andere Felder), was die Handhabung erschwert. Aber für ein Start-up ist das Schema-Schema überwältigend faszinierend, da schnelle Iteration und Time-to-Market (und oft zu Recht) ausschlaggebend sind. 

2
Remus Rusanu

Sie haben uns gebeten anzunehmen, dass entweder die Daten auf eine einzelne Maschine passen können. OR Ihre Datenbank verfügt über eine effektive Auto-Sharding-Funktion.

Wenn Sie davon ausgehen, dass Ihre SQL-Daten über eine Funktion zum automatischen Sharding verfügen, bedeutet dies, dass Sie über die Ausführung eines Clusters sprechen. Jedes Mal, wenn Sie ein Cluster von Computern ausführen, müssen Sie sich um die Fehlertoleranz sorgen.

Angenommen, Sie verwenden den einfachsten Ansatz zum Verteilen Ihrer Daten nach Anwendungsfunktion und speichern alle Daten Ihres Benutzerkontos auf Server A und Ihren Produktkatalog auf Server B.

Ist es für Ihr Unternehmen akzeptabel, wenn Server A ausfällt und sich keiner Ihrer Benutzer anmelden kann?

Ist es für Ihr Unternehmen akzeptabel, wenn Server B ausfällt und niemand etwas kaufen kann?

Wenn nicht, müssen Sie sich um das Einrichten der Datenreplikation und das Failover mit hoher Verfügbarkeit kümmern. Machbar, aber für SQL-Datenbanken nicht angenehm oder einfach. Andere Arten von Sharding-Strategien (Schlüssel, Suchdienst usw.) haben die gleichen Herausforderungen.

Viele NoSQL-Datenbanken behandeln Replikationen und Failovers automatisch. Einige erledigen dies ohne großen Konfigurationsaufwand. Das ist aus betrieblicher Sicht ein großer Vorteil.

Vollständige Offenlegung: Ich bin Ingenieur bei FoundationDB, einer NoSQL-Datenbank, die automatisch Sharding, Replikation und Failover mit sehr wenig Konfiguration abwickelt. Es hat auch eine SQL-Schicht , damit Sie keine strukturierten Daten aufgeben müssen.

0
jrullmann