CouchDB .view-Datei außer Kontrolle geraten?

Question

Ich habe kürzlich eine Situation festgestellt, in der meine CouchDB-Instanz den gesamten verfügbaren Speicherplatz auf einer VM-Instanz mit 20 GB verwendet hat. Bei der Untersuchung entdeckte ich, dass ein Verzeichnis in/usr/local/var/lib/couchdb/eine Reihe von .view-Dateien enthielt, von denen die größte 16 GB war. Ich konnte die * .view-Dateien entfernen, um den normalen Betrieb wiederherzustellen. Ich bin nicht sicher, warum die .view-Dateien so groß wurden und wie CouchDB .view-Dateien verwaltet.

Ein bisschen mehr Informationen. Ich habe eine VM mit Ubuntu 9.10 (karmic) mit 512 MB und CouchDB 0.10. Die VM hat einen Cron-Job, der ein Python-Skript aufruft, das eine Ansicht abfragt. Der Cron-Job wird alle fünf Minuten ausgeführt. Jedes Mal, wenn die Ansicht abgefragt wird, erhöht sich die Größe einer .view-Datei. Ich habe einen Job geschrieben, um dies stündlich zu überwachen, und nach ein paar Tagen sehe ich die Datei nicht rollt oder in anderer Größe abnimmt.

Hat jemand Einblick in dieses Problem? Gibt es ein Dokument, das ich vermisst habe? Ich konnte nichts zu dem Thema finden, aber das könnte daran liegen, dass ich an den falschen Stellen oder meinen Suchbegriffen nachgesehen habe.

Answer 1

CouchDB ist sehr Festplatten-hungrig, Handel Speicherplatz für die Leistung. Ansichten werden größer, wenn ihnen Elemente hinzugefügt werden. Sie können Speicherplatz, der nicht mehr benötigt wird, mit Bereinigung und Komprimierung wiederherstellen.

Jedes Mal, wenn Sie ein Update erstellen oder ein Dokument löschen, werden die View-Indizes mit den relevanten Änderungen an den Dokumenten aktualisiert. Die Aktualisierung der Ansicht wird durchgeführt, wenn sie abgefragt wird. Wenn Sie also viele Dokumentänderungen vornehmen, sollten Sie erwarten, dass Ihr Index wächst und mit Komprimierung und Bereinigung verwaltet werden muss.

Wenn Ihre Ansichten für einen bestimmten Satz von Dokumenten sehr groß sind, haben Sie möglicherweise schlecht gestaltete Ansichten. Alternativ kann Ihr Entwurf nur große Ansichten erfordern und Sie müssen das wie jede andere Ressource verwalten.

Es wäre einfacher zu sagen, was passiert, wenn Sie beschreiben könnten, welche Dokumentaktualisierungen (inc create und delete) stattfinden und was Ihre Ansichtsfunktionen ausgeben, besonders für die große Ansicht.

Answer 2

Die Größe Ihrer .view-Dateien wächst jedes Mal, wenn Sie auf eine Ansicht zugreifen, weil CouchDB die Zugriffsansichten aktualisiert. CouchDB-Ansichten benötigen eine Komprimierung wie Datenbanken. Wenn Sie häufig Änderungen an Ihren Dokumenten vornehmen, die zu Änderungen in Ihrer Ansicht führen, sollten Sie von Zeit zu Zeit die Ansichtsverdichtung durchführen. Siehe http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction

Um die Größe Ihrer Ansichten zu reduzieren, sehen Sie sich die Daten an, die Sie aussenden. Wenn Sie (foo, doc) ausgeben, wird das gesamte Dokument in die Ansicht kopiert, in der es sehr schnell verfügbar ist, wenn Sie die Ansicht abfragen. die Funktion (doc) {emit (doc.title, doc); } ergibt eine Ansicht, die so groß ist wie die Datenbank selbst. Sie könnten auch ausgeben (doc.title, nil); Verwenden Sie die Option include_docs, damit CouchDB das Dokument aus der Datenbank abrufen kann, wenn Sie auf die Ansicht zugreifen (was zu einer leichten Leistungseinbuße führt). Siehe http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options

Answer 3

Verwenden sequenzielle oder monotones IDs für Dokumente anstelle von zufälligen

Ja, couchdb sehr Scheibe hungrig ist, und es muss regelmäßig Verdichtungen. Aber es gibt eine andere Sache, die dazu beitragen kann, diese Festplattennutzung zu reduzieren, besonders manchmal, wenn es unnötig ist.

Couchdb verwendet B + Bäume zum Speichern von Daten/Dokumenten, was eine sehr gute Datenstruktur für die Durchführung der Datenabfrage darstellt. Die Verwendung von B-Tree wird jedoch für die Speicherplatznutzung mit der Leistung verglichen. Mit völlig zufälliger Id fächert B + -Baum schnell auf.Da die minimale Füllrate für jeden internen Knoten die Hälfte beträgt, werden die Knoten meist bis zur Hälfte gefüllt (da sich die Daten aufgrund ihrer Zufälligkeit gleichmäßig verteilen), wodurch mehr interne Knoten erzeugt werden. Auch neue Einfügungen können ein Neuschreiben des gesamten Baumes verursachen. Das ist, was Zufälligkeit verursachen kann;)

Stattdessen kann die Verwendung von sequential or monotonic IDs alle vermeiden.

Answer 4

Ich hatte dieses Problem auch, CouchDB für ein Browsed-basierte Spiel auszuprobieren.

Wir hatten ungefähr 100.000 unerwartete Besucher am ersten Tag eines Aufstellungsortstarts, und innerhalb 2 Tage nahm die CouchDB Datenbank ungefähr 40GB im Raum. Dies hat den Server zum Absturz gebracht, weil das HD vollständig voll war.

Komprimierung brachte das zurück auf etwa 50 MB. Ich habe auch die _revs_limit (die standardmäßig auf 1000 gesetzt ist) auf 10 gesetzt, da uns die Überarbeitungshistorie egal war, und sie läuft seitdem einwandfrei. Nach fast 1 Mio. Benutzern beträgt die Datenbankgröße normalerweise etwa 2-3 GB. Wenn ich komprimiere, ist es ungefähr 500MB.

einstellen Dokument Revision Grenze bis 10:
curl -X PUT -d "10" http://dbuser:dbpassword@127.0.0.1:5984/yourdb/_revs_limit

oder ohne Benutzer: Passwort (nicht empfohlen):
curl -X PUT -d "10" http://127.0.0.1:5984/yourdb/_revs_limit