Ich möchte Zähler in einem CouchDB Dokument speichern, die bei jedem Seitenaufruf erhöht werden. CouchDB wird eine komplette Revision dieses Dokuments für nur eine Zähleraktualisierung erstellen.
Würde dies nicht zu viel Platz beanspruchen? Wenn man bedenkt, dass ich 1 Mio. Zugriffe pro Tag habe, könnte ich mit 1 Mio. Überarbeitungen des Dokuments pro Tag rechnen.
Irgendwelche Gedanken dazu...
Merci !
CouchDB ist sehr explizit über die Kompromisse, die es eingeht. In diesem speziellen Fall geht es darum, eine absturzsichere Datenbank zu haben, die leider viel Speicherplatz verbrauchen kann und wird, bis sie kompaktiert ist.
Sie erhalten damit Zuverlässigkeit und eine Menge Gleichzeitigkeit beim Lesen. Sie erhalten auch die Möglichkeit, nahtlos mit anderen Knoten zu replizieren. Das ist der Clou an der Sache. Die Notwendigkeit, wegen gestoßener Zähler zu kompaktieren, ist das Schlimme daran. Vergessen Sie es, mit _rev_limit herumzupfuschen. Sie werden sich damit selbst in die Scheiße reiten, weil Revisionen so grundlegend für Couch sind.
Eine Möglichkeit, die Sie haben, ist die Protokollierung einiger Informationen, des Datums und der Uhrzeit, der IPs und anderer Dinge. Sie würden dann eine Ansicht erstellen, die die Daten ausgibt, die Sie benötigen, und _count als Ihre Reduktionsfunktion verwenden. Auf diese Weise erhalten Sie die benötigten Informationen und einige andere möglicherweise wertvolle Daten für die Analyse. Dies ist die Lösung "einfach eine Ansicht erstellen".
Die zweite Möglichkeit wäre die Verwendung von [redis] ( http://redis.io/commands/incr ). Redis ist ganz nett und würde gut zu diesem Anwendungsfall passen ( http://ai.mee.nu/is_couchdb_the_anti-redis ). Dies wäre die Lösung "das richtige Werkzeug für die richtige Aufgabe".
Die dritte Möglichkeit wäre, sie einfach zu ignorieren. Möglicherweise ist es überhaupt kein Problem (wenn Sie häufig kompaktieren). Dies wäre die Lösung "einfach entspannen".
Man muss das Gute mit dem Schlechten abwägen und sicherstellen, dass die Vorteile die Nachteile überwiegen. Messen Sie alles zweimal, bevor Sie kürzen/optimieren.
Ich glaube nicht, dass das möglich ist.
Eine alternative Lösung wäre, den Zähler in einem kleinen Dokument zu platzieren, und die Verdichtung in regelmäßigen Abständen darauf. Das ist nicht optimal, aber es minimiert den belegten Platz.
Sie können auch erwägen, etwas wie Memcached (oder Membase) als "Counter Storage" zu verwenden. Damit können Sie die Zähler aktualisieren, ohne zusätzliche Revisionen in CouchDB zu erzeugen. Ich gehe davon aus, dass Sie nicht alle Zwischenstände des Zählers benötigen (da Sie sagen, dass Sie die Revisionen nicht behalten wollen), so dass es Sinn macht, sie in etwas zu speichern, das für diesen Anwendungsfall besser geeignet ist.
Wenn Sie keine Replikation benötigen, können Sie den Zähler in einem _lokalen Dokument speichern. Lokale Dokumente haben keine Versionsgeschichte. Sie können sie auch speichern, ohne ihre Revision zu kennen. Sie werden nicht repliziert, die letzte Version gewinnt immer.
Zum Erstellen/Aktualisieren eines _lokalen Dokuments verwenden Sie einfach PUT /db/_local/[DOCID]
Sie können Ihr _lokales Dokument abrufen mit GET /db/_local/[DOCID]
Wir haben ein kleines Experiment gemacht...
Das Dokument war standardmäßig auf 1000 Umdrehungen begrenzt, hatte etwa 100kb Anhänge, 1 Integer-Zähler, den wir ständig erhöhten
Am Ende wurden etwa 4 GB Festplattenkapazität für etwa 200.000 Inkremente verwendet. Durch Verdichtung konnte die Größe auf etwa 6 KB reduziert werden.
Was für ein Pech!
Meine ernsthaften Bedenken sind nun - häufige Verdichtung (vielleicht stündlich/zweimal täglich/etc) auf einer schreibintensiven Couch-Instanz laufen!
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
