CouchDB .view file in crescita fuori controllo?

Question

Recentemente ho riscontrato una situazione in cui la mia istanza CouchDB utilizzava tutto lo spazio disponibile su un'istanza VM da 20 GB. Dopo un'indagine ho scoperto che una directory in/usr/local/var/lib/couchdb/conteneva un gruppo di file .view, il più grande dei quali era di 16 GB. Sono stato in grado di rimuovere i file * .view per ripristinare il normale funzionamento. Non sono sicuro del motivo per cui i file .view sono cresciuti così tanto e come CouchDB gestisce i file .view.

Un po 'più di informazioni. Ho una macchina virtuale con Ubuntu 9.10 (karmico) con 512 MB e CouchDB 0.10. La VM ha un processo cron che richiama uno script Python che interroga una vista. Il lavoro cron viene eseguito una volta ogni cinque minuti. Ogni volta che viene interrogata la vista, la dimensione di un file .view aumenta. Ho scritto un lavoro per monitorarlo su base oraria e dopo alcuni giorni non vedo il file che si sta capovolgendo o diminuendo di dimensioni.

Qualcuno ha qualche approfondimento su questo problema? C'è un pezzo di documentazione che ho perso? Non sono stato in grado di trovare nulla sull'argomento, ma potrebbe essere dovuto a cercare nei posti sbagliati o ai miei termini di ricerca.

Answer 1

CouchDB è molto affamato di disco, scambia spazio su disco per prestazioni. Le viste aumenteranno di dimensioni man mano che gli oggetti vengono aggiunti a loro. È possibile recuperare lo spazio su disco che non è più necessario con la pulizia e la compattazione.

Ogni volta che si crea un aggiornamento o si elimina un documento, gli indici delle viste verranno aggiornati con le modifiche pertinenti ai documenti. L'aggiornamento alla vista avverrà quando viene interrogato. Quindi, se stai facendo molte modifiche ai documenti, dovresti aspettarti che il tuo indice cresca e che debba essere gestito con compattazione e pulizia.

Se le visualizzazioni sono molto grandi per un determinato set di documenti, è possibile che le viste siano progettate male. In alternativa, il tuo progetto potrebbe richiedere solo visualizzazioni grandi e dovrai gestirlo come faresti con qualsiasi altra risorsa.

Sarebbe più facile dire cosa sta succedendo se potessi descrivere quali aggiornamenti del documento (inc creare ed eliminare) stanno accadendo e quali sono le funzioni di visualizzazione che stanno emettendo, specialmente per la vista ampia.

Answer 2

Che i file .view crescano, ogni volta che si accede a una vista è perché CouchDB aggiorna le viste sull'accesso. Le viste CouchDB richiedono anche la compattazione come i database. Se si verificano frequenti modifiche ai documenti, con conseguenti cambiamenti nella vista, è necessario eseguire di volta in volta la compattazione della vista. Vedi http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction

Per ridurre la dimensione delle visualizzazioni, dai un'occhiata ai dati che stai emettendo. Quando si emette (foo, doc) l'intero documento viene copiato nella vista per renderlo immediatamente disponibile quando si interroga la vista. la funzione (doc) {emit (doc.title, doc); } risulterà in una vista grande quanto il database stesso. Potresti anche emettere (doc.title, nil); e utilizzare l'opzione include_docs per consentire a CouchDB di recuperare il documento dal database quando si accede alla vista (il che si tradurrà in una leggera penalizzazione delle prestazioni). Vedere http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options

Answer 3

uso sequenziale o id monotone di documenti, invece di casuale

Sì, CouchDB è molto rigido fame, e ha bisogno di compattazioni regolari. Ma c'è un'altra cosa che può aiutare a ridurre questo utilizzo del disco, specialmente a volte quando non è necessario.

Couchdb utilizza alberi B + per la memorizzazione di dati/documenti che è una struttura dati molto buona per le prestazioni di recupero dei dati. Tuttavia l'uso di B-tree si traduce in prestazioni per l'utilizzo dello spazio su disco. Con Id completamente casuale, B + -tree fan rapidamente.Poiché il tasso di riempimento minimo è 1/2 per ogni nodo interno, i nodi sono per lo più riempiti fino a 1/2 (poiché i dati si distribuiscono uniformemente a causa della casualità) generando più nodi interni. Anche i nuovi inserimenti possono causare una riscrittura dell'albero completo. Questo è ciò che la casualità può causare;)

Invece, l'uso di id sequential or monotonic può evitare tutto.

Answer 4

Ho avuto questo problema, provando CouchDB per un gioco basato su browser.

Abbiamo avuto circa 100.000 visitatori inaspettati il ​​primo giorno di lancio di un sito e in 2 giorni il database CouchDB ha impiegato circa 40 GB di spazio. Ciò ha reso il server in crash perché l'HD era completamente pieno.

La compattazione lo ha riportato a circa 50 MB. Ho anche impostato il valore _revs_limit (che ha valore predefinito su 1000) su 10 poiché non ci interessa la cronologia delle revisioni e da allora funziona perfettamente. Dopo quasi 1 milione di utenti, la dimensione del database è in genere di circa 2-3 GB. Quando eseguo la compattazione è di circa 500 MB.

impostazione del limite di revisione del documento di 10:
curl -X PUT -d "10" http://dbuser:dbpassword@127.0.0.1:5984/yourdb/_revs_limit

O senza utente: password (sconsigliato):
curl -X PUT -d "10" http://127.0.0.1:5984/yourdb/_revs_limit