Struttura del documento consigliata per CouchDB

Question

Attualmente stiamo valutando la possibilità di passare da Postgres a CouchDB per un'applicazione di monitoraggio dell'utilizzo. Alcuni numeri:

Circa 2000 connessioni, interrogate ogni 5 minuti, per circa 600.000 nuove righe al giorno. In Postgres, archiviamo questo dato, diviso per giorno:

t_usage {service_id, timestamp, DATA_IN, data_out}
t_usage_20100101 eredita t_usage.
t_usage_20100102 eredita t_usage. ecc.

Scriviamo i dati con un proc ottimizzato memorizzato che presume che la partizione esista e la crei se necessario. Possiamo inserire molto rapidamente.

Per la lettura dei dati, il nostro casi d'uso, in ordine di importanza e le prestazioni attuali sono:
* Servizio singolo, Festa e getta: la buona prestazione
* Servizi multipli, Mese Uso: Prestazione scarsa
* Singolo Servizio, mese di utilizzo: scarso rendimento
* Servizi multipli, Mesi multiple: prestazioni molto scarse
* Servizi multiple, giorno singola: buona prestazione

Ciò ha senso perché le partizioni sono ottimizzati per giorni, che è di gran lunga il nostro più imp caso d'uso ortant. Tuttavia, stiamo esaminando i metodi per migliorare i requisiti secondari.

Spesso è necessario parametrizzare la query per ore, ad esempio, dando solo risultati tra le 8 e le 18, quindi le tabelle di riepilogo sono di uso limitato. (Questi parametri cambiano con frequenza sufficiente che la creazione di più tabelle di dati di riepilogo è proibitiva).

Con questo background, la prima domanda è: CouchDB è appropriato per questi dati? Se lo è, visti i casi di utilizzo di cui sopra, come modellerebbero meglio i dati nei documenti CouchDB? Alcune opzioni Ho messo insieme fino ad ora, che siamo nel processo di analisi comparativa sono (_id, escluso _rev):

un documento per collegamento giornalieri

{ 
    service_id:555 
    day:20100101 
    usage: {1265248762: {in:584,out:11342}, 1265249062: {in:94,out:1242}} 
} 

circa 60.000 nuovi documenti al mese. La maggior parte dei nuovi dati sarebbero aggiornamenti di documenti esistenti, piuttosto che nuovi documenti.

(Qui, gli oggetti in uso sono immessi nel timestamp del sondaggio e i valori in byte e fuori).

un documento per connessione al mese

{ 
    service_id:555 
    month:201001 
    usage: {1265248762: {in:584,out:11342}, 1265249062: {in:94,out:1242}} 
} 

circa 2.000 nuovi documenti al mese. Sono necessari aggiornamenti moderati ai documenti esistenti.

un documento per riga dei dati raccolti

{ 
    service_id:555 
    timestamp:1265248762 
    in:584 
    out:11342 
} 
{ 
    service_id:555 
    timestamp:1265249062 
    in:94 
    out:1242 
} 

circa 15 milioni di nuovi documenti al mese. Tutti i dati sarebbero un inserto in un nuovo documento. Inserti più veloci, ma ho domande su quanto sarà efficiente dopo un anno o 2 anni con centinaia di milioni di documenti. Il file IO sembrerebbe proibitivo (anche se sono il primo ad ammettere di non comprendere appieno la meccanica di esso).

Sto cercando di avvicinarmi a questo in un modo orientato al documento, anche se interrompere l'abitudine RDMS è difficile :) Il fatto che tu possa solo parametrizzare solo minimamente le viste mi ha un po 'preoccupato. Detto questo, quale di questi sarebbe il più appropriato? Ci sono altri formati che non ho considerato che funzioneranno meglio?

Grazie in anticipo,

Jamie.

Answer 1

Non penso che sia un'idea orribile.

Consideriamo lo scenario di connessione/mese.

Dato che una voce è lunga ~ 40 (che è generosa), e ottieni ~ 8.200 voci al mese, la dimensione del documento finale sarà di ~ 350 K alla fine del mese.

Ciò significa che, a pieno ritmo, stai leggendo e scrivendo 2000 documenti da 350.000 ogni 5 minuti.

I/O saggio, questo è inferiore a 6 MB/s, considerando la lettura e la scrittura, media per la finestra di 5 m di tempo. Oggi è benissimo anche nell'hardware di fascia bassa.

Tuttavia, c'è un altro problema. Quando archivi quel documento, Couch valuterà i suoi contenuti per costruire la sua vista, quindi Couch analizzerà 350K documenti. La mia paura è che (all'ultima verifica, ma è passato un po 'di tempo), non credo che Couch abbia scalato bene tra i core della CPU, quindi questo potrebbe facilmente bloccare il core della singola CPU che Couch utilizzerà. Mi piacerebbe sperare che Couch possa leggere, analizzare ed elaborare 2 MB/s, ma francamente non lo so. Con tutti i suoi benefici, l'erlang non è il migliore in un linguaggio informatico.

L'ultima preoccupazione è stare al passo con il database. Questo scriverà 700 MB ogni 5 minuti alla fine del mese. Con l'architettura Couchs (solo aggiunta), si scriveranno 700 MB di dati ogni 5 minuti, ovvero 8,1 GB all'ora e 201 GB dopo 24 ore.

Dopo la compressione DB, si riduce a 700 MB (per un singolo mese), ma durante tale processo, il file diventerà grande e abbastanza rapidamente.

Sul lato di recupero, questi documenti di grandi dimensioni non mi spaventano. Caricando un documento JSON da 350K, sì è grande, ma non è così grande, non sull'hardware moderno. Ci sono avatar su bacheche più grandi di così. Quindi, qualsiasi cosa tu voglia fare riguardo l'attività di una connessione più di un mese sarà piuttosto veloce, penso. Attraverso le connessioni, ovviamente più si afferra, più costosa sarà (700 MB per tutte le connessioni 2000). 700 MB è un numero reale che ha un impatto reale. Inoltre, il tuo processo dovrà essere aggressivo nel buttare via i dati che non ti interessano, in modo che possa buttare via il chaff (a meno che tu non voglia caricare 700 MB di heap nel tuo processo di report).

Dato questi numeri, Connection/Day può essere una soluzione migliore, in quanto è possibile controllare la granularità un po 'meglio. Comunque, sinceramente, sceglierei il documento più grossolano possibile, perché penso che ti dia il miglior valore dal database, solo perché oggi tutte le ricerche di testa e le rotazioni del piatto sono ciò che uccide un sacco di prestazioni I/O, molti dischi flusso di dati molto bene. Documenti più grandi (assumendo dati ben localizzati, dato che Couch è costantemente compattato, questo non dovrebbe essere un problema) trasmettono più che cercare. Cercare in memoria è "libero" rispetto a un disco.

Con tutti i mezzi esegui i tuoi test sul nostro hardware, ma prendi a cuore tutte queste considerazioni.

EDIT:

Dopo più esperimenti ...

Un paio di osservazioni interessanti.

Durante l'importazione di documenti di grandi dimensioni, la CPU è ugualmente importante per la velocità di I/O. Ciò è dovuto alla quantità di marshalling e CPU consumata convertendo il JSON nel modello interno per l'utilizzo da parte delle viste. Usando i grandi documenti (350k), le mie CPU erano praticamente al massimo (350%). Al contrario, con i documenti più piccoli, stavano canticchiando al 200%, anche se, nel complesso, erano le stesse informazioni, solo divise in modo diverso.

Per I/O, durante i 350.000 documenti, stavo rilevando 11 MB/sec, ma con i documenti più piccoli, era solo 8 MB/sec.

La compattazione sembrava quasi il limite I/O. È difficile per me ottenere buoni numeri sul mio potenziale I/O. Una copia di un file memorizzato nella cache spinge 40 + MB/sec. La compattazione è avvenuta a circa 8MB/sec. Ma questo è coerente con il carico grezzo (supponendo che il divano si muova di messaggi di roba per messaggio). La CPU è più bassa, poiché sta facendo meno elaborazione (non sta interpretando i payload JSON, o ricostruendo le viste), in più è stata una singola CPU a fare il lavoro.

Infine, per la lettura, ho provato a scaricare l'intero database. Una singola CPU è stata cavigliata per questo, e il mio I/O piuttosto basso. Ho fatto un punto per assicurarmi che il file CouchDB non fosse effettivamente memorizzato nella cache, la mia macchina ha molta memoria, quindi molte cose sono memorizzate nella cache. Il dump raw attraverso _all_docs era solo di circa 1 MB/sec. Questo è quasi tutto il ritardo di ricerca e rotazione di qualsiasi altra cosa. Quando l'ho fatto con i documenti di grandi dimensioni, l'I/O stava colpendo 3 MB/sec, che mostra solo l'effetto streaming che ho citato un vantaggio per i documenti più grandi.

E va notato che sul sito Web di Couch esistono tecniche sul miglioramento delle prestazioni che non stavo seguendo. In particolare stavo usando ID casuali. Infine, questo non è stato fatto per valutare quale sia la performance di Couch, piuttosto dove il carico sembra finire. Le differenze tra documento grande e piccolo sono state interessanti.

Infine, le prestazioni finali non sono tanto importanti quanto il semplice risultato di prestazioni sufficienti per l'applicazione con l'hardware. Come hai detto, stai facendo tu stesso test, e questo è tutto ciò che conta davvero.