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

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

• Cassandra (tabellarisch, in Java geschrieben, verwendet von Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit und Twitter)
• CouchDB (Dokument, geschrieben in Erlang, verwendet von BBC und Engine Yard)
• Dynomite (Schlüsselwert, geschrieben in Erlang, verwendet von Powerset)
• HBase (Schlüsselwert, in Java geschrieben, von Bing verwendet)
• Hypertabelle (tabellarisch, in C ++ geschrieben, von Baidu verwendet)
• Kai (Schlüsselwert, geschrieben in Erlang)
• MemcacheDB (Schlüsselwert, in C geschrieben, von Reddit verwendet)
• MongoDB (Dokument, geschrieben in C ++, verwendet von Electronic Arts, Github, NY Times und Sourceforge)
• Neo4j (Grafik, in Java geschrieben, von einigen schwedischen Universitäten verwendet)
• Projekt Voldemort (Schlüsselwert, in Java geschrieben, von LinkedIn verwendet)
• Redis (Schlüsselwert, geschrieben in C, verwendet von Craigslist, Engine Yard und Github)
• Riak (Schlüsselwert, geschrieben in Erlang, verwendet von Comcast und Mochi Media)
• Ringo (Schlüsselwert, geschrieben in Erlang, verwendet von Nokia)
• Scalaris (Schlüsselwert, geschrieben in Erlang, verwendet von OnScale)
• 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 würde gerne wissen, welche spezifischen Probleme Sie - der SO-Reader - mithilfe von Datenspeichern gelöst haben und welchen NoSQL-Datenspeicher Sie verwendet haben.

Fragen:

• Welche Skalierbarkeitsprobleme haben Sie mithilfe von NoSQL-Datenspeichern gelöst?
• 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. Bitte antworten Sie nicht, es sei denn, Sie haben diese.

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

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

Leider reagierte die Traceback-Logger-Website kurz nach der Veröffentlichung nicht mehr. Wir hatten einige Sperrprobleme mit der Produktionsdatenbank unserer Hauptwebsite, die fast bei jeder Anforderung Ausnahmen auslösten, sowie einige andere Fehler, die wir während der Testphase nicht untersucht haben. Der Servercluster unserer Hauptwebsite, der als Traceback-Logger-Submit-Seite bezeichnet wird, wird mehrmals pro Sekunde angezeigt. Und das war viel zu viel für den kleinen Server, auf dem sich der Traceback-Logger befand (es war bereits ein alter Server, der nur für Entwicklungszwecke verwendet wurde).

Zu dieser Zeit war CouchDB ziemlich beliebt, und so beschloss ich, es auszuprobieren und einen kleinen Traceback-Logger damit zu schreiben. Der neue Logger bestand nur aus einer einzelnen Python-Datei, die eine Fehlerliste mit Sortier- und Filteroptionen sowie eine Übermittlungsseite enthielt. Und im Hintergrund habe ich einen CouchDB-Prozess gestartet. Die neue Software reagierte extrem schnell auf alle Anfragen und wir konnten die enorme Menge an automatischen Fehlerberichten anzeigen.

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

Jetzt läuft der schnell geschriebene CouchDB-Traceback-Logger noch und ist eine hilfreiche Möglichkeit, Fehler auf der Hauptwebsite zu untersuchen. Jedenfalls wird die Datenbank ungefähr einmal im Monat zu groß und der CouchDB-Prozess wird beendet. Aber dann reduziert der Befehl compact-db von CouchDB die Größe von mehreren GB auf einige KB und die Datenbank ist wieder betriebsbereit (vielleicht sollte ich dort einen Cronjob hinzufügen ... 0o).

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

Mein aktuelles Projekt eigentlich.

Speichern von 18.000 Objekten in einer normalisierten Struktur: 90.000 Zeilen in 8 verschiedenen Tabellen. Es dauerte 1 Minute, um sie abzurufen und unserem Java-Objektmodell zuzuordnen, da alles korrekt indiziert ist usw.

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

In geschäftlicher Hinsicht: Die erste Option war nicht realisierbar. Die zweite Option bedeutet, dass unsere App funktioniert.

Technologiedetails: Laufen auf MySQL für SQL und NoSQL! Halten Sie sich an MySQL, um eine gute Transaktionsunterstützung, Leistung und nachgewiesene Erfolgsbilanz zu erzielen, damit Daten nicht beschädigt werden, die Skalierung recht gut erfolgt, Clustering unterstützt wird usw.

Unser Datenmodell in MySQL besteht jetzt nur noch aus Schlüsselfeldern (Ganzzahlen) und dem großen "Wert" -Feld: im Grunde genommen nur ein großes TEXT-Feld.

Wir haben uns für keinen der neuen Player (CouchDB, Cassandra, MongoDB usw.) entschieden, da sie zwar jeweils für sich genommen großartige Funktionen bieten, jedoch immer Nachteile für unsere Umstände aufwiesen (z. B. fehlende / unreife Java-Unterstützung).

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

Update: Hier ist ein Beispiel dafür, wie wir Textinhalte dargestellt haben, nicht unsere eigentliche Geschäftsdomäne (wir arbeiten nicht mit "Produkten"), wie mein Chef mich erschießen würde, sondern die Idee, einschließlich des rekursiven Aspekts (hier eine Entität) ein Produkt, das andere "enthält"). Hoffentlich ist klar, wie in einer normalisierten Struktur dies einige Tabellen sein können, z. B. das Verbinden eines Produkts mit seinem Geschmacksspektrum, 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}
]

Todd Hoffs highscalability.com bietet eine großartige Berichterstattung über NoSQL, einschließlich einiger Fallstudien.

Das kommerzielle säulenförmige DBMS von Vertica könnte Ihren Zwecken entsprechen (obwohl es SQL unterstützt): Es ist im Vergleich zu herkömmlichen relationalen DBMS für Analyseabfragen sehr schnell. Siehe das kürzlich erschienene CACM-Papier von Stonebraker et al., In dem Vertica mit Kartenreduzierung verglichen wird.

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

Update 2: Rick Cattell hat gerade einen Vergleich mehrerer NoSQL-Systeme in High Performance Data Stores veröffentlicht . Und die Version von highscalability.com zu Ricks Papier ist da .

Wir haben einen Teil unserer Daten von MySQL nach Mongodb verschoben, nicht so sehr aus Gründen der Skalierbarkeit, sondern vielmehr, weil sie besser für Dateien und nicht tabellarische Daten geeignet sind.

In der Produktion lagern wir derzeit:

• 25.000 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 unter Verwendung der Mongodb-Python-API (Pymongo) bereitgestellt. 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 Blockierung des Mongodb-Servers war dies eine gute Erfahrung.

Ich entschuldige mich dafür, dass ich gegen Ihren kühnen Text verstoßen habe, da ich keine Erfahrungen aus erster Hand habe, aber diese Blog-Beiträge sind ein gutes Beispiel für die Lösung eines Problems mit CouchDB.

CouchDB: Eine Fallstudie

Im Wesentlichen verwendete die textme- Anwendung CouchDB, um das explodierende Datenproblem zu lösen. Sie stellten fest, dass SQL zu langsam war, um große Mengen an Archivdaten zu verarbeiten, und verschoben sie in CouchDB. Es ist eine ausgezeichnete Lektüre und er bespricht den gesamten Prozess, um herauszufinden, welche Probleme CouchDB lösen könnte und wie sie letztendlich gelöst wurden.

Wir haben einige unserer Daten, die wir in Postgresql und Memcached gespeichert haben, in Redis verschoben . Schlüsselwertspeicher eignen sich viel besser zum Speichern hierarchischer Objektdaten. Sie können Blob-Daten 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" });

Schlüsselwertspeicher lassen sich auch viel einfacher skalieren, da Sie einen neuen Server hinzufügen und dann Ihre Last gleichmäßig aufteilen können, um den neuen Server einzuschließen. Wichtig ist, 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 Anforderungen zu verteilen).

Ich betrachte Redis als eine "verwaltete Textdatei" auf Steroiden, die einen schnellen, gleichzeitigen und atomaren Zugriff für mehrere Clients bietet. Alles, was ich früher für die Verwendung einer Textdatei oder einer eingebetteten Datenbank verwendet habe, verwende ich jetzt Redis. zB Um ein kombiniertes rollierendes Fehlerprotokoll in Echtzeit für alle unsere Dienste zu erhalten (was für uns notorisch eine schwierige Aufgabe war), wird dies jetzt mit nur wenigen Zeilen erreicht, indem der Fehler nur einer Redis-Serverseitenliste und vorangestellt wird Trimmen Sie dann die Liste so, dass nur die letzten 1000 erhalten bleiben, 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);

Ich habe keine Erfahrungen aus erster Hand, aber ich fand diesen Blogeintrag ziemlich interessant.

Ich finde, dass das Zuordnen von Software-Domänenobjekten (z. B. aSalesOrder, aCustomer ...) zu einer zweidimensionalen relationalen Datenbank (Zeilen und Spalten) viel Code zum Speichern / Aktualisieren und zum erneuten Instanziieren einer Domänenobjektinstanz aus mehreren Tabellen erfordert . Ganz zu schweigen von dem Leistungseinbruch all dieser Verknüpfungen, all dieser Festplattenlesevorgänge ... nur um ein Domänenobjekt wie einen Kundenauftrag oder einen Kundendatensatz anzuzeigen / zu bearbeiten.

Wir haben auf Object Database Management Systems (ODBMS) umgestellt. Sie liegen außerhalb 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 enthalten. Als Klassenvorteil für Entwickler ist Ihre Klassenhierarchie automatisch Ihr Datenbankschema, Ihre Unterklassen und alles. Verwenden Sie einfach Ihre objektorientierte Sprache, um Objekte für die Datenbank dauerhaft zu machen. ODBMS-Systeme bieten eine Transaktionsintegrität auf ACID-Ebene, sodass sie auch in Finanzsystemen funktionieren.

Ich habe für ein M2M-System von MySQL (InnoDB) zu Cassandra gewechselt, in dem im Grunde Zeitreihen von Sensoren für jedes Gerät gespeichert sind. Alle Daten werden durch (Geräte-ID, Datum) und (Geräte-ID, Typ des Sensors, Datum) indiziert. Die MySQL-Version enthielt 20 Millionen Zeilen.

MySQL:

• Setup in Master-Master-Synchronisation. Beim Verlust der Synchronisation traten nur wenige Probleme auf . Es war stressig und vor allem am Anfang konnte es Stunden dauern, es zu reparieren.
• Die Einfügezeit war kein Problem, aber das Abfragen erforderte mit zunehmendem Datenwachstum immer mehr Speicher . 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 es nicht möglich war, das Schema für schwere Tabellen zu aktualisieren , da es viel zu viel Zeit (Stunden) dauerte.
• Das Importieren von Daten dauerte Stunden (auch wenn die Indizierung am Ende durchgeführt wurde). Der beste Rettungsplan bestand darin, immer ein paar Kopien der Datenbank (Datendatei + Protokolle) aufzubewahren.
• Der Wechsel von einem Hosting-Unternehmen zu einem anderen war wirklich eine große Sache . Die Replikation musste sehr sorgfältig behandelt werden.

Kassandra:

• Noch einfacher zu installieren als MySQL.
• Benötigt viel RAM. Eine 2-GB-Instanz konnte in den ersten Versionen nicht ausgeführt werden. Jetzt kann sie auf einer 1-GB-Instanz ausgeführt werden, aber es ist keine Idee (viel zu viele Datenbereinigungen). In unserem Fall war es genug, 8 GB zu geben.
• Sobald Sie verstanden haben, wie Sie Ihre Daten organisieren, ist das Speichern einfach. Das Anfordern ist etwas komplexer. Aber wenn Sie es einmal umgangen haben, ist es sehr schnell (Sie können keine Fehler machen, wenn Sie es nicht wirklich wollen).
• Wenn der vorherige Schritt richtig gemacht wurde, ist und bleibt er superschnell.
• Es scheint fast so, als ob Daten so organisiert sind, dass sie gesichert 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 Upgrades) zu löschen, damit das Wiederherstellen weniger Zeit in Anspruch nimmt, da wir weniger Protokolle zum Lesen haben. Es werden nicht viele Dateien erstellt, wenn sie komprimiert sind.
• Das Importieren von Daten ist höllisch schnell. Und je mehr Hosts Sie haben, desto schneller. Das Exportieren und Importieren von Gigabyte an Daten ist kein Problem mehr.
• Es ist sehr interessant, kein Schema zu haben, da Sie Ihre Daten so entwickeln können, dass sie Ihren Anforderungen entsprechen. Dies kann bedeuten, dass sich verschiedene Versionen Ihrer Daten gleichzeitig in derselben Spaltenfamilie befinden.
• Das Hinzufügen eines Hosts war einfach (allerdings nicht schnell), aber ich habe es bei einem Setup mit mehreren Rechenzentren nicht durchgeführt.

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

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

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

Ich habe MongoDB ausprobiert und es war 40 Mal schneller als Sqlite, also sollte ich es vielleicht verwenden. Ich hoffe aber immer noch auf eine einfache Lösung in Bearbeitung.

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

Wir haben eine Postgres-Datenbank durch eine CouchDB-Dokumentendatenbank ersetzt, da es für uns ein großer Vorteil war, kein festes Schema zu haben. Jedes Dokument verfügt über eine variable Anzahl von Indizes, die für den Zugriff auf dieses Dokument verwendet werden.

Ich habe in der Vergangenheit Couchbase verwendet und wir sind auf Probleme beim Ausgleich und auf eine Vielzahl anderer Probleme gestoßen. 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 , das zeigt, wie Redis in einem Anbietermodell verwendet und Ihre C # -Objekte in Redis gespeichert werden. Schau mal.

Ich würde jedem, der dies liest, empfehlen, Couchbase noch einmal auszuprobieren, da 3.0 draußen ist. Für den Anfang gibt es über 200 neue Funktionen. Die Leistung, Verfügbarkeit, Skalierbarkeit und einfachen 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 Load Balancer von der Anwendung zur Datenbank erforderlich ist. Obwohl wir derzeit keinen verwalteten Service haben, können Sie Couchbase auf Dingen wie AWS, RedHat Gears, Cloudera, Rackspace, Docker-Containern wie CloudSoft und vielem mehr ausführen. In Bezug auf die Neuausrichtung hängt es davon ab, worauf Sie sich speziell beziehen, aber Couchbase wird nach einem Knotenausfall nicht automatisch neu ausgelegt, wie geplant. Ein Administrator kann jedoch ein automatisches Failover für den ersten Knotenfehler einrichten. Mithilfe unserer APIs können Sie auch auf die Replikat-Vbuckets zugreifen, um sie zu lesen, bevor Sie sie aktivieren, oder mithilfe der RestAPI können Sie ein Failover durch ein Überwachungstool erzwingen. Dies ist ein Sonderfall, der jedoch möglich ist.

Wir neigen dazu, in so ziemlich jedem Modus keine Neuverteilung durchzuführen, es sei denn, der Knoten ist vollständig offline und kommt nie wieder oder ein neuer Knoten ist bereit, automatisch ausgeglichen zu werden. Im Folgenden finden Sie einige Anleitungen, die allen Interessierten helfen sollen, herauszufinden, worum es bei einer der leistungsstärksten NoSQL-Datenbanken geht.

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

Zuletzt möchte ich Sie auch ermutigen, N1QL für verteilte Abfragen zu testen:

1. N1QL Tutorial
2. N1QL-Handbuch

Vielen Dank fürs Lesen und lassen Sie mich oder andere wissen, wenn Sie weitere Hilfe benötigen!

Austin

Ich habe Vertica in der Vergangenheit verwendet. Es basiert auf kolumnarer Komprimierung und beschleunigt das Lesen von Datenträgern und senkt den Speicherbedarf, um Ihre Hardware optimal zu nutzen. Durch schnelleres Laden von Daten und höhere Parallelität können Sie Analysedaten mit minimaler Latenz für mehr Benutzer bereitstellen.

Zuvor haben wir die Oracle-Datenbank mit Milliarden von Datensätzen abgefragt und die Leistung war sehr suboptimal. Die Ausführung der Abfragen dauerte 8 bis 12 Sekunden, auch nach der Optimierung mit SSD. Aus diesem Grund hatten wir das Bedürfnis, eine schneller leseoptimierte, analyseorientierte Datenbank zu verwenden. Mit Vertica Clustern hinter der Lean-Service-Schicht konnten wir APIs mit einer Leistung von weniger als einer Sekunde ausführen.

Vertica speichert Daten in Projektionen in einem Format, das die Ausführung von Abfragen optimiert. Ähnlich wie bei materialisierten Ansichten speichern Projektionen Ergebnismengen auf Festplatte ODER SSD, anstatt sie jedes Mal zu berechnen, wenn sie in einer Abfrage verwendet werden. Projektionen bieten die folgenden Vorteile:

1. Komprimieren und codieren Sie Daten, um den Speicherplatz zu reduzieren.
2. Vereinfachen Sie die Verteilung im Datenbankcluster.
3. Bieten Sie hohe Verfügbarkeit und Wiederherstellung.

Vertica optimiert die Datenbank, indem 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 durch.
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 unter https://www.vertica.com/knowledgebase/.