Perché i miei database CouchDB crescono così in fretta?

Question

Mi stavo chiedendo perché il mio database CouchDB stava crescendo velocemente così ho scritto un po 'test script. Questo script modifica un attributo di un documento CouchDB 1200 volte e prende la dimensione del database dopo ogni modifica. Dopo aver eseguito questi 1200 passi di scrittura, il database esegue un compaction step e la dimensione del db viene misurata di nuovo. Alla fine lo script traccia la dimensione del database rispetto ai numeri di revisione. L'analisi comparativa viene eseguito due volte:

• La prima volta che viene utilizzato il numero predefinito di revisione del documento (= 1000) (_revs_limit).
• La seconda volta il numero di revisioni del documento è impostato su 1.

La prima esecuzione produce il seguente grafico

first run http://i46.tinypic.com/xayydw.png

La seconda esecuzione produce questa trama

second run http://i50.tinypic.com/2l92l8w.png

Per me questo è un comportamento abbastanza inaspettato. Nella prima fase mi sarei aspettato una crescita lineare poiché ogni cambiamento produce una nuova revisione. Quando vengono raggiunte le 1000 revisioni, il valore della dimensione deve essere costante mentre le revisioni precedenti vengono scartate. Dopo la compattazione, le dimensioni dovrebbero diminuire in modo significativo.

Nella seconda esecuzione la prima revisione dovrebbe comportare determinate dimensioni del database che vengono quindi mantenute durante le seguenti fasi di scrittura poiché ogni nuova revisione porta alla cancellazione di quella precedente.

Potrei capire se c'è un po 'di overhead necessario per gestire i cambiamenti ma questo comportamento di crescita mi sembra strano. Qualcuno può spiegare questo fenomeno o correggere le mie supposizioni che portano a aspettative sbagliate?

Answer 1

Prima di tutto, CouchDB salva alcune informazioni anche per le revisioni eliminate (solo l'ID e l'identificatore di revisione), perché ne ha bisogno a scopo di replica.

In secondo luogo, l'inserimento dei documenti uno alla volta non è ottimale a causa del modo in cui i dati vengono salvati su disco (vedere WikiPedia), ciò potrebbe spiegare la crescita superlineare nel primo grafico.