Kann CouchDB Tausende von separaten Datenbanken verwalten?

Question

Kann CouchDB Tausende von separaten Datenbanken auf demselben Rechner verwalten?

Stellen Sie sich vor Sie haben eine Sammlung von BankTransaction s. Es gibt viele tausend Datensätze. (BEARBEITEN: keine Transaktionen wirklich speichern - denken Sie nur an eine sehr große Anzahl von sehr kleinen, häufig aktualisierten Datensätzen. Es ist im Grunde eine Join-Tabelle von SQL-Land.)

Jeder Tag möchten Sie eine Zusammenfassung der Transaktionen, die aufgetreten sind nur bei Ihrer örtlichen Bankfiliale. Wenn sich alle Datensätze in einer einzelnen Datenbank befinden, wird beim Regenerieren der Ansicht der Transaktionen der Zweigstellen verarbeitet. Dies ist ein viel größerer Teil der Arbeit und unnötig für den Benutzer, der sich nur um seine bestimmte Teilmenge von Dokumenten kümmert.

Dadurch scheint es so, als ob jeder Bankzweig in eine eigene Datenbank partitioniert werden sollte, damit die Ansichten in kleineren Blöcken und unabhängig voneinander erzeugt werden können. Aber ich habe nie von jemandem gehört, der das macht, und es scheint wie ein Anti-Pattern (z. B. das Duplizieren des gleichen Design-Dokuments in Tausenden von verschiedenen Datenbanken).

Gibt es eine andere Art, wie ich dieses Problem modellieren sollte? (Sollte die Partitionierung zwischen getrennten Rechnern stattfinden, nicht getrennte Datenbanken auf demselben Rechner?) Wenn nicht, kann CouchDB die Tausende von Datenbanken verwalten, die benötigt werden, um die Partitionen klein zu halten?

(Danke!)

Answer 1

[Warnung, ich nehme an, Sie sind diese Produktionsumgebung in einer Art ausgeführt wird. Geh einfach mit der kurzen Antwort, wenn das für ein Schul- oder Haustierprojekt ist.]

Die kurze Antwort ist "ja".

Die längere Antwort ist, dass es einige Dinge, die Sie müssen aufpassen für ...

• Sie gehen mit vielen Systemeinstellungen wie maximale Datei Whack-a-Mole zu spielen Deskriptoren.

• Sie spielen auch whack-a-mole mit erlang vm-Einstellungen.

• CouchDB hat eine Option "max offene Datenbanken". Steigern Sie dies, oder Sie werden ausstehende Anforderungen häufen.

• Es wird eine PITA sein, um mehrere Datenbanken zu aggregieren, um Berichte zu generieren. Sie können dies tun, indem Sie den _changes-Feed jeder Datenbank abfragen, die Daten ändern und sie dann in eine zentrale/aggregierende Datenbank zurückwerfen. Die Tools, um dies zu erleichtern, sind in der CouchDB-API noch nicht verfügbar. Fast, aber nicht ganz.

jedoch das größte Problem, das Sie in laufen gehen, wenn Sie versuchen, dies zu tun, ist, dass CouchDB nicht horizontal Skala [gut] von selbst tut. Wenn Sie weitere CouchDB-Server hinzufügen, haben sie alle Duplikate der Daten. Sicher, Ihre maximale offene dbs-Zahl wird linear mit jedem hinzugefügten Knoten skaliert, aber andere Dinge wie die Aufbauzeit der Ansicht werden nicht funktionieren (z. B. müssen sie alle ihre eigenen Ansichten erstellen).

Während ich Tausende von geöffneten Datenbanken auf einem BigCouch Cluster gesehen habe.Anekdotisch liegt das an Dynamo-Clustering: mehr Knoten machen verschiedene Dinge parallel, im Gegensatz zu abgeschirmten CouchDB-Servern, die sich gegenseitig replizieren.

Prost.

Answer 2

Mehrere Datenbanken sind möglich, aber in den meisten Fällen glaube ich, dass die Gesamtdatenbank Ihren Zweigstellen eine bessere Leistung bringt. Denken Sie daran, dass Sie nur optimieren, wenn ein Dokument in die Ansicht aktualisiert wird. Jedes Dokument wird nur einmal pro Ansicht geparst.

Für die Abfrage am Ende des Tages in einer Gesamtdatenbank bewirkt der erste Zweig, dass 100% der neuen Dokumente verarbeitet werden, und zahlt 100% der Verzögerung. Alle anderen Filialen zahlen 0%. So profitieren die meisten Branchen. Für die Abfrage am Ende des Tages in separaten Datenbanken zahlen alle Zweigstellen einen Teil der Strafe proportional zu ihrem Volumen, so dass die meisten leicht hinterherhinken.

Für regelmäßige Updates während des Tages bevorzugen aktive Zweigstellen die Aggregate und Zweigstellen mit geringem Volumen bevorzugen separate. Wenn eine Verzweigung in 10 99% der Dokumente hinzufügt, werden die meisten Aktualisierungsarbeiten an den Abstimmungen anderer Zweige durchgeführt, so dass 9 von 10 separate dbs bevorzugen.

Wenn diese Latenz von Bedeutung ist und angenommen wird, dass einige Taktzyklen unbenutzt sind, könnten Sie ein 3-zeiliges loop/view/sleep Shell-Skript schreiben, das einige Dokumente aktualisiert, bevor ein Benutzer darauf wartet.

Answer 3

Ich würde hinzufügen, dass mit einer großen Anzahl von Datenbanken Probleme rund um die Komprimierung und Replikation erstellt. Nicht nur, dass Dinge wie fortlaufende Replikation auf einer Datenbankbasis ausgelöst werden müssen (das heißt, Sie müssen benutzerdefinierte Logik schreiben, um alle Datenbanken zu durchlaufen), aber sie erzeugen auch Replikationsdämonen pro Datenbank. Dies kann schnell prohibitiv werden.