wake-up-neo.com

Welche Skalierbarkeitsprobleme sind bei der Verwendung eines NoSQL-Datenspeichers aufgetreten?

NoSQL bezieht sich auf nicht relationale Datenspeicher, die mit der Historie relationaler Datenbanken und ACID-Garantien brechen. Beliebte Open Source-NoSQL-Datenspeicher umfassen:

  • Cassandra (tabellarisch, in Java geschrieben, verwendet von Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit und Twitter)
  • CouchDB (Dokument, in Erlang geschrieben, von BBC und Engine Yard verwendet)
  • Dynomite (Schlüsselwert, geschrieben in Erlang, wird von Powerset verwendet)
  • HBase (Schlüsselwert, geschrieben in Java, von Bing verwendet)
  • Hypertable (tabellarisch in C++ geschrieben, von Baidu verwendet)
  • Kai (Schlüsselwert, geschrieben in Erlang)
  • MemcacheDB (Schlüsselwert, geschrieben in C, von Reddit verwendet)
  • MongoDB (Dokument, geschrieben in C++, verwendet von Electronic Arts, Github, NY Times und Sourceforge)
  • Neo4j (in Java geschriebenes Diagramm, das von einigen schwedischen Universitäten verwendet wird)
  • Project Voldemort (Schlüsselwert, geschrieben in Java, von LinkedIn verwendet)
  • Redis (Schlüsselwert in C geschrieben, von Craigslist, Engine Yard und Github verwendet)
  • Riak (Schlüsselwert, geschrieben in Erlang, verwendet von Comcast und Mochi Media)
  • Ringo (Schlüsselwert, geschrieben in Erlang, von Nokia verwendet)
  • Scalaris (Schlüsselwert, geschrieben in Erlang, von OnScale verwendet)
  • Terrastore (Dokument, geschrieben in Java)
  • ThruDB (Dokument, geschrieben in C++, verwendet von JunkDepot.com)
  • Tokyo Cabinet/Tokyo Tyrant (Schlüsselwert, geschrieben in C, verwendet von Mixi.jp (japanische Social-Networking-Site))

Ich möchte wissen, welche Probleme Sie - der SO - Leser - mit Hilfe von Datenspeichern gelöst haben und welchen NoSQL-Datenspeicher Sie verwendet haben.

Fragen:

  • Welche Skalierbarkeitsprobleme haben Sie zur Lösung von NoSQL-Datenspeichern verwendet?
  • Welchen NoSQL-Datenspeicher haben Sie verwendet? 
  • Welche Datenbank haben Sie vor dem Wechsel zu einem NoSQL-Datenspeicher verwendet?

Ich bin auf der Suche nach Erfahrungen aus erster Hand, also antworten Sie bitte nicht, es sei denn.

189
knorv

Ich habe ein kleines Teilprojekt von MySQL auf CouchDB umgestellt, um die Last handhaben zu können. Das Ergebnis war unglaublich.

Vor etwa zwei Jahren haben wir eine selbstgeschriebene Software auf http://www.ubuntuusers.de/ veröffentlicht (wahrscheinlich die größte deutsche Linux-Community-Website). Die Site ist in Python geschrieben und wir haben eine WSGI-Middleware hinzugefügt, mit der alle Ausnahmen erfasst und an eine andere kleine MySQL-basierte Website gesendet werden konnten. Diese kleine Website verwendete einen Hash, um verschiedene Fehler zu ermitteln, und die Anzahl der Vorkommen sowie das letzte Vorkommen gespeichert.

Leider reagierte die Traceback-Logger-Website kurz nach der Veröffentlichung nicht mehr. Wir hatten einige Probleme mit der Produktion unserer Haupt-Site, die fast jede Anfrage auslöste, sowie einige andere Fehler, die wir in der Testphase nicht untersucht haben. Das Server-Cluster unserer Hauptsite, die so genannte Traceback-Logger-Übergabeseite, wird mehrere Male pro Sekunde aufgerufen. Und das war für den kleinen Server, der den Traceback-Logger hostete, viel zu viel (es war bereits ein alter Server, der nur zu Entwicklungszwecken verwendet wurde).

Zu dieser Zeit war CouchDB ziemlich beliebt, und so entschied ich mich, es auszuprobieren und einen kleinen Traceback-Logger damit zu schreiben. Der neue Logger bestand nur aus einer einzigen Python-Datei, die eine Fehlerliste mit Sortier- und Filteroptionen sowie eine Übergabeseite enthielt. Und im Hintergrund habe ich einen CouchDB-Prozess gestartet. Die neue Software hat sehr schnell auf alle Anfragen reagiert und wir konnten die enormen Mengen an automatischen Fehlerberichten einsehen.

Interessant ist, dass die Lösung zuvor auf einem alten dedizierten Server ausgeführt wurde, auf dem die neue CouchDB-basierte Site jedoch nur auf einer gemeinsam genutzten Xen-Instanz mit sehr begrenzten Ressourcen lief. Und ich habe noch nicht einmal die Stärke der Schlüsselwertspeicher genutzt, um horizontal zu skalieren. Die Fähigkeit von CouchDB/Erlang OTP, gleichzeitige Anforderungen zu bearbeiten, ohne etwas zu sperren, war bereits ausreichend, um die Anforderungen zu erfüllen.

Nun ist der schnell geschriebene CouchDB-Traceback-Logger noch in Betrieb und ist eine hilfreiche Methode, um Fehler auf der Hauptwebsite zu untersuchen. Jedenfalls wird die Datenbank etwa einmal im Monat zu groß und der CouchDB-Prozess wird beendet. Mit dem Befehl compact-db von CouchDB wird die Größe jedoch wieder von einigen GB auf einige KB reduziert, und die Datenbank ist wieder betriebsbereit.

Zusammenfassend war CouchDB für dieses Teilprojekt sicherlich die beste Wahl (oder zumindest eine bessere Wahl als MySQL) und macht seine Arbeit gut.

49
tux21b

Mein aktuelles Projekt eigentlich.

18.000 Objekte in einer normalisierten Struktur speichern: 90.000 Zeilen in 8 verschiedenen Tabellen. Es dauerte 1 Minute, um sie abzurufen und unserem Java-Objektmodell zuzuordnen. Das heißt, alles ist korrekt indiziert usw.

Speichern Sie sie als Schlüssel/Wert-Paare mit einer einfachen Textdarstellung: 1 Tabelle, 18.000 Zeilen, 3 Sekunden, um sie alle abzurufen und die Java-Objekte zu rekonstruieren.

Aus geschäftlicher Sicht war die erste Option nicht realisierbar. Zweite Option bedeutet, dass unsere App funktioniert.

Technologiedetails: auf MySQL für SQL und NoSQL laufen! Bleiben Sie bei MySQL für gute Transaktionsunterstützung, Leistung und nachgewiesene Erfolgsbilanz, um Daten nicht zu beschädigen, ziemlich gut zu skalieren, Unterstützung für Clustering usw. 

Unser Datenmodell in MySQL besteht jetzt nur aus Schlüsselfeldern (Ganzzahlen) und dem großen Wertefeld: Im Grunde nur ein großes TEXT-Feld.

Wir haben uns nicht für einen der neuen Player entschieden (CouchDB, Cassandra, MongoDB usw.), da sie zwar jeweils großartige Features/Leistungen bieten, es jedoch immer Nachteile für unsere Umstände gab (z. B. fehlende/unausgereifte Java-Unterstützung).

Zusätzlicher Vorteil der (ab) Verwendung von MySQL - die Bits unseres Modells, die do relational arbeiten, können leicht mit unseren Schlüssel-/Wertspeicherdaten verknüpft werden.

Update: Hier ist ein Beispiel, wie wir Textinhalte dargestellt haben, nicht unsere eigentliche Geschäftsdomäne (wir arbeiten nicht mit "Produkten"), während mein Chef mich erschießt, sondern die Idee vermittelt, einschließlich des rekursiven Aspekts (hier eine Entität) ein Produkt, das andere "enthält"). Hoffentlich ist es klar, wie dies in einer normalisierten Struktur eine Reihe von Tabellen sein kann, z. Verbinden eines Produkts mit seinem Aromastoff, welche anderen Produkte enthalten sind, usw

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={Nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]
50
Brian

Der highscalability.com von Todd Hoff bietet eine umfassende Abdeckung von NoSQL, einschließlich einiger Fallstudien. 

Das kommerzielle Vertica -Spalten-DBMS kann für Ihre Zwecke geeignet sein (obwohl es SQL unterstützt): Es ist sehr schnell im Vergleich zu herkömmlichen relationalen DBMS für Analyseabfragen. Vgl. Stonebraker et al. Recent CACM paper , bei dem Vertica mit Map-Reduce verglichen wird.

Update: Und Twitter hat Cassandra über mehrere andere ausgewählt, darunter HBase, Voldemort, MongoDB, MemcacheDB, Redis und HyperTable.

Update 2: Rick Cattell hat kürzlich einen Vergleich mehrerer NoSQL-Systeme in High Performance Data Stores veröffentlicht. Und highscalability.com's Einstellung zu Ricks Papier ist here .

22
Jim Ferrans

Wir haben einen Teil unserer Daten von mysql nach mongodb verschoben, nicht so sehr aus Skalierbarkeit, sondern mehr, weil sie besser für Dateien und nicht tabellarische Daten geeignet sind.

In der Produktion lagern wir derzeit:

  • 25 Tausend Dateien (60 GB)
  • 130 Millionen andere "Dokumente" (350 GB)

mit einem Tagesumsatz von rund 10 GB.

Die Datenbank wird in einer "gepaarten" Konfiguration auf zwei Knoten (6x450 GB sas raid10) mit Apache/wsgi/python-Clients bereitgestellt, die die Mongodb-Python-API (Pymongo) verwenden. Das Festplatten-Setup ist wahrscheinlich übertrieben, aber das ist es, was wir für mysql verwenden.

Abgesehen von einigen Problemen mit Pymongo-Threadpools und der Sperrung des mongodb-Servers war dies eine gute Erfahrung.

8
serbaut

Ich entschuldige mich dafür, dass Sie gegen Ihren mutigen Text verstoßen haben, da ich keine Erfahrung aus erster Hand habe. Diese Reihe von Blogbeiträgen ist jedoch ein gutes Beispiel für die Lösung eines Problems mit CouchDB.

CouchDB: Eine Fallstudie

Im Wesentlichen hat die Anwendung textme / CouchDB verwendet, um das explodierende Datenproblem zu lösen. Sie stellten fest, dass SQL zu langsam war, um mit großen Mengen an Archivdaten umzugehen, und verlagerten es auf CouchDB. Es ist eine exzellente Lektüre und er diskutiert den gesamten Prozess, um herauszufinden, welche Probleme CouchDB lösen kann und wie sie diese lösen.

5
TwentyMiles

Wir haben einige unserer Daten, die wir in Postgresql und Memcached gespeichert haben, nach Redis verschoben. Schlüsselwertspeicher eignen sich viel besser zum Speichern von hierarchischen Objektdaten. Sie können Blobdaten viel schneller und mit viel weniger Entwicklungszeit und -aufwand speichern als mit einem ORM, um Ihren Blob einem RDBMS zuzuordnen.

Ich habe einen open source c # redis-Client , mit dem Sie alle POCO-Objekte mit einer Zeile speichern und abrufen können:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Das Speichern von Schlüsselwerten ist auch viel einfacher zu skalieren, da Sie einen neuen Server hinzufügen und die Last gleichmäßig aufteilen können, um den neuen Server einzubeziehen. Es ist wichtig, dass es keinen zentralen Server gibt, der Ihre Skalierbarkeit einschränkt. (obwohl Sie immer noch eine Strategie für konsistentes Hashing benötigen, um Ihre Anfragen zu verteilen).

Ich halte Redis für eine "verwaltete Textdatei" auf Steroiden, die einen schnellen, gleichzeitigen und atomaren Zugriff für mehrere Clients ermöglicht. Alles, was ich früher für Textdateien oder eingebettete Datenbanken verwendet habe, verwende ich jetzt mit Redis. z.B. Um ein Echtzeit-Fehlerprotokoll für alle unsere Dienste zu erhalten (was für uns eine schwierige Aufgabe gewesen ist), wird es jetzt mit nur wenigen Zeilen erledigt, indem der Fehler einfach an eine Redis-Serverseitenliste angehängt wird und dann die Liste so beschneiden, dass nur die letzten 1000 beibehalten werden, z.

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);
5
mythz

Ich habe keine Erfahrungen aus erster Hand., Aber ich fand den Blogeintrag this ziemlich interessant.

4
Michel

Ich finde den Aufwand, Software-Domänenobjekte (z. B. aSalesOrder, aCustomer ...) in eine zweidimensionale relationale Datenbank (Zeilen und Spalten) abzubilden, erfordert viel Code zum Speichern/Aktualisieren und dann zum Instanziieren einer Domänenobjektinstanz aus mehreren Tabellen . Ganz zu schweigen von der Leistung, wenn all diese Joins, alle diese Festplatten gelesen werden, nur um ein Domain-Objekt wie einen Kundenauftrag oder einen Kundendatensatz anzuzeigen/zu bearbeiten. 

Wir haben zu Object Database Management Systems (ODBMS) gewechselt. Sie sind jenseits der Möglichkeiten der aufgeführten noSQL-Systeme. Der GemStone/S (für Smalltalk) ist ein solches Beispiel. Es gibt andere ODBMS-Lösungen, die Treiber für viele Sprachen haben. Ein entscheidender Vorteil für Entwickler: Ihre Klassenhierarchie besteht automatisch aus Ihrem Datenbankschema, Unterklassen und allen. Verwenden Sie einfach Ihre objektorientierte Sprache, um Objekte für die Datenbank persistent zu machen. ODBMS-Systeme bieten eine Transaktionsintegrität auf ACID-Ebene, sodass sie auch in Finanzsystemen funktioniert.

3
peter ode

Ich nicht. Ich würde gerne einen einfachen und kostenlosen Schlüsselwertspeicher verwenden, den ich im Prozess aufrufen kann, aber auf der Windows-Plattform gibt es so etwas nicht. Jetzt benutze ich Sqlite, aber ich möchte etwas wie Tokyo Cabinet verwenden. BerkeleyDB hat Lizenzprobleme. 

Wenn Sie jedoch das Windows-Betriebssystem verwenden möchten, ist die Auswahl der NoSQL-Datenbanken begrenzt. Und es gibt nicht immer einen C # -Anbieter 

Ich habe MongoDB ausprobiert und es war 40 Mal schneller als Sqlite. Vielleicht sollte ich es verwenden. Ich hoffe jedoch immer noch auf eine einfache In-Prozess-Lösung. 

2
Theo

Ich habe Redis verwendet, um Protokollnachrichten auf mehreren Computern zu speichern. Es war sehr einfach zu implementieren und sehr nützlich. Redis rockt wirklich

2
GabiMe

Wir haben eine Postgres-Datenbank durch eine CouchDB-Dokumentendatenbank ersetzt, da uns ein festes Schema nicht gut getan hat. Jedes Dokument verfügt über eine variable Anzahl von Indizes, die für den Zugriff auf dieses Dokument verwendet werden.

2
SorcyCat

Ich habe von MySQL (InnoDB) zu Cassandra für ein M2M-System gewechselt, das grundsätzlich Zeitreihen von Sensoren für jedes Gerät speichert. Alle Daten werden nach (Geräte-ID, Datum) und (Geräte-ID, Typ_des_Sensors, Datum) indexiert. Die MySQL-Version enthielt 20 Millionen Zeilen.

MySQL:

  • Setup in Master-Master-Synchronisation. In der Nähe von Synchronisationsverlust trat nur ein kleines Problem auf. Es war anstrengend und vor allem anfangs konnte es Stunden dauern, das Problem zu beheben.
  • Die Einfügungszeit war kein Problem, aber Abfragen erforderte immer mehr Speicher, da die Daten wuchsen. Das Problem ist, dass die Indizes als Ganzes betrachtet werden. In meinem Fall habe ich nur sehr dünne Teile der Indizes verwendet, die zum Laden in den Speicher erforderlich waren (nur wenige Prozent der Geräte wurden häufig überwacht und es wurden die neuesten Daten verwendet).
  • Es war schwer zu sichern. Rsync kann keine schnellen Sicherungen für große InnoDB-Tabellendateien durchführen.
  • Es wurde schnell klar, dass das Schema für schwere Tabellen konnte nicht aktualisiert werden, weil es viel zu viel Zeit (Stunden) benötigte.
  • Importieren von Daten dauerte Stunden (auch wenn die Indexierung am Ende durchgeführt wurde). Der beste Rettungsplan bestand darin, immer einige Kopien der Datenbank (Datendatei + Protokolle) aufzubewahren.
  • Umzug von einem Hosting-Unternehmen zu einem anderen war wirklich eine große Sache. Die Replikation musste sehr sorgfältig gehandhabt werden.

Kassandra:

  • Noch einfacher zu installieren als MySQL.
  • Benötigt viel RAM. Eine 2-GB-Instanz konnte nicht in den ersten Versionen ausgeführt werden, jetzt kann sie mit einer 1-GB-Instanz ausgeführt werden, aber es ist keine Idee (viel zu viele Datenbereinigungen). In unserem Fall genügte es 8 GB.
  • Sobald Sie wissen, wie Sie Ihre Daten organisieren, ist das Speichern einfach. Das Beantragen ist etwas komplexer. Aber wenn Sie einmal herum gekommen sind, ist es wirklich schnell (Sie können keinen Fehler machen, wenn Sie nicht wirklich wollen).
  • Wenn der vorherige Schritt richtig gemacht wurde, ist und bleibt er superschnell.
  • Es scheint fast, als wären Daten organisiert, um gesichert zu werden. Alle neuen Daten werden als neue Dateien hinzugefügt. Ich persönlich, aber es ist keine gute Sache, Daten jede Nacht und vor jedem Herunterfahren (normalerweise für ein Upgrade) zu spülen, sodass die Wiederherstellung weniger Zeit in Anspruch nimmt, da weniger Protokolle gelesen werden müssen. Es werden nicht viele Dateien erstellt, wenn sie komprimiert sind.
  • Das Importieren von Daten ist extrem schnell. Und je mehr Hosts, desto schneller. Das Exportieren und Importieren von Gigabytes an Daten ist kein Problem mehr.
  • Ein Schema nicht zu haben, ist eine sehr interessante Sache, weil Sie Ihre Daten entsprechend Ihren Bedürfnissen weiterentwickeln können. Dies kann bedeuten, dass unterschiedliche Versionen Ihrer Daten gleichzeitig in derselben Spaltenfamilie vorhanden sind.
  • Das Hinzufügen eines Hosts war einfach (allerdings nicht schnell), aber ich habe es in einem Multi-Datacenter-Setup nicht getan.

Hinweis: Ich habe auch elasticsearch (Dokument basierend auf Lucene) verwendet, und ich denke, es sollte als NoSQL-Datenbank betrachtet werden. Es ist verteilt, zuverlässig und oft schnell (einige komplexe Abfragen können sehr schlecht funktionieren).

2
Florent

Ich würde jeden, der dies liest, ermutigen, Couchbase noch einmal zu versuchen, jetzt, da 3.0 aus der Tür ist. Für den Anfang gibt es über 200 neue Funktionen. Die Leistung, Verfügbarkeit, Skalierbarkeit und einfache Verwaltungsfunktionen von Couchbase Server sorgen für eine äußerst flexible, hochverfügbare Datenbank. Die Verwaltungsoberfläche ist integriert, und die APIs erkennen die Clusterknoten automatisch, sodass kein Lastausgleich zwischen Anwendung und DB erforderlich ist. Während wir derzeit keinen verwalteten Dienst haben, können Sie couchbase für Dinge wie AWS, RedHat Gears, Cloudera, Rackspace, Docker-Container wie CloudSoft und vieles mehr ausführen. In Bezug auf das Rebalancing hängt es davon ab, worauf Sie sich gerade beziehen, aber Couchbase baut das Design nach einem Knotenausfall nicht automatisch auf. Ein Administrator kann jedoch ein automatisches Failover für den ersten Knotenausfall einrichten Replikat-Vbuckets zum Lesen vor dem Aktivieren oder zum Verwenden der RestAPI können Sie ein Failover durch ein Überwachungstool erzwingen. Dies ist ein Sonderfall, der jedoch möglich ist. 

Wir neigen dazu, in fast keinem Modus eine Neuverteilung vorzunehmen, es sei denn, der Knoten ist vollständig offline und kommt nie wieder zurück oder ein neuer Knoten kann automatisch ausgeglichen werden. Hier sind ein paar Anleitungen, die jedem helfen können, zu sehen, worum es bei einer der leistungsfähigsten NoSQL-Datenbanken geht.

  1. Couchbase Server 3.0
  2. Administrationshandbuch
  3. REST API
  4. Entwicklerhandbücher

Zum Schluss möchte ich Sie auch dazu ermutigen, N1QL für verteilte Abfragen zu überprüfen:

  1. N1QL Tutorial
  2. N1QL Guide

Danke fürs Lesen und lass mich oder andere wissen, wenn du mehr Hilfe brauchst!

Austin

1
Austin Gonyou

Ich habe in der Vergangenheit Couchbase verwendet und wir hatten Probleme mit der Neuverteilung und dem Host anderer Probleme. Derzeit verwende ich Redis in mehreren Produktionsprojekten. Ich verwende redislabs.com , einen verwalteten Dienst für Redis, der sich um die Skalierung Ihrer Redis-Cluster kümmert. Ich habe in meinem Blog unter http://thomasjaeger.wordpress.com ein Video zur Objektpersistenz veröffentlicht, in dem gezeigt wird, wie Redis in einem Providermodell verwendet wird und wie Ihre C # -Objekte in Redis gespeichert werden. Schau mal.

1
Thomas Jaeger

Ich habe Vertica in der Vergangenheit verwendet. Es basiert auf der säulenförmigen Komprimierung und beschleunigt das Lesen von Festplatten und senkt den Speicherbedarf, um das Beste aus Ihrer Hardware zu machen. Durch das schnellere Laden von Daten und eine höhere Parallelität können Sie Analysedaten mehr Benutzern mit minimaler Latenz bereitstellen.

Zuvor haben wir Oracle-Datenbanken mit Milliarden von Datensätzen abgefragt und die Leistung war nicht optimal. Die Abfragen dauerten 8 bis 12 Sekunden, auch nach der Optimierung mit SSD. Daher hatten wir das Bedürfnis, eine schneller lesefreundliche, auf Analysen ausgerichtete Datenbank zu verwenden. Mit Vertica-Clustern hinter der Lean-Service-Schicht können wir APIs mit einer Leistung unter einer Sekunde ausführen.

Vertica speichert Daten in Projektionen in einem Format, das die Abfrageausführung optimiert. Ähnlich wie bei materialisierten Ansichten speichern Projektionen Resultsets auf Festplatte OR SSD, anstatt sie bei jeder Verwendung in einer Abfrage zu berechnen. Projektionen bieten die folgenden Vorteile:

  1. Daten komprimieren und kodieren, um Speicherplatz zu sparen.
  2. Vereinfachen Sie die Verteilung im Datenbankcluster.
  3. Sorgen Sie für hohe Verfügbarkeit und Wiederherstellung.

Vertica optimiert die Datenbank, indem die Daten mithilfe der Segmentierung über den Cluster verteilt werden.

  1. Durch die Segmentierung wird ein Teil der Daten auf einem Knoten platziert.
  2. Es verteilt die Daten gleichmäßig auf alle Knoten. Somit führt jeder Knoten einen Teil des Abfrageprozesses aus.
  3. Die Abfrage wird im Cluster ausgeführt, und jeder Knoten erhält den Abfrageplan
  4. Die Ergebnisse der Abfragen werden aggregiert und zum Erstellen der Ausgabe Verwendet.

Weitere Informationen finden Sie in der Vertica-Dokumentation @ https://www.vertica.com/knowledgebase/

0
Vik