Quali problemi di scalabilità hai riscontrato utilizzando un archivio dati NoSQL? [chiuso]

NoSQL si riferisce ad archivi di dati non relazionali che rompono con la storia dei database relazionali e le garanzie ACID. Gli archivi di dati NoSQL open source popolari includono:

• Cassandra (tabulare, scritto in Java, utilizzato da Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit e Twitter)
• CouchDB (documento, scritto in Erlang, utilizzato da BBC e Engine Yard)
• Dynomite (valore-chiave, scritto in Erlang, usato da Powerset)
• HBase (valore-chiave, scritto in Java, utilizzato da Bing)
• Hypertable (tabulare, scritto in C ++, usato da Baidu)
• Kai (valore-chiave, scritto in Erlang)
• MemcacheDB (valore-chiave, scritto in C, utilizzato da Reddit)
• MongoDB (documento, scritto in C ++, utilizzato da Electronic Arts, Github, NY Times e Sourceforge)
• Neo4j (grafico, scritto in Java, utilizzato da alcune università svedesi)
• Progetto Voldemort (valore-chiave, scritto in Java, utilizzato da LinkedIn)
• Redis (valore-chiave, scritto in C, utilizzato da Craigslist, Engine Yard e Github)
• Riak (valore-chiave, scritto in Erlang, utilizzato da Comcast e Mochi Media)
• Ringo (valore-chiave, scritto in Erlang, usato da Nokia)
• Scalaris (valore-chiave, scritto in Erlang, usato da OnScale)
• Terrastore (documento, scritto in Java)
• ThruDB (documento, scritto in C ++, utilizzato da JunkDepot.com)
• Tokyo Cabinet / Tokyo Tyrant (valore-chiave, scritto in C, utilizzato da Mixi.jp (sito di social network giapponese))

Mi piacerebbe conoscere problemi specifici che tu, il lettore SO, hai risolto usando gli archivi dati e quale archivio dati NoSQL hai usato.

Domande:

• Quali problemi di scalabilità hai usato per risolvere gli archivi di dati NoSQL?
• Quale archivio dati NoSQL hai utilizzato?
• Quale database hai usato prima di passare a un archivio dati NoSQL?

Sto cercando esperienze di prima mano, quindi per favore non rispondere a meno che tu non lo abbia.

Ho passato un piccolo sottoprogetto da MySQL a CouchDB, per essere in grado di gestire il carico. Il risultato è stato sorprendente.

Circa 2 anni fa, abbiamo rilasciato un software scritto su http://www.ubuntuusers.de/ (che è probabilmente il più grande sito Web della comunità Linux tedesca). Il sito è scritto in Python e abbiamo aggiunto un middleware WSGI che è stato in grado di catturare tutte le eccezioni e inviarle a un altro piccolo sito Web basato su MySQL. Questo piccolo sito Web utilizzava un hash per determinare diversi bug e memorizzava anche il numero di occorrenze e l'ultima occorrenza.

Sfortunatamente, poco dopo il rilascio, il sito Web di traceback-logger non rispondeva più. Abbiamo avuto alcuni problemi di blocco con il db di produzione del nostro sito principale che generava eccezioni quasi ogni richiesta, così come molti altri bug, che non abbiamo esplorato durante la fase di test. Il cluster di server del nostro sito principale, chiamato pagina di invio del traceback-logger diverse k volte al secondo. E questo era troppo per il piccolo server che ospitava il logger di traceback (era già un vecchio server, che veniva utilizzato solo a scopi di sviluppo).

A quel tempo CouchDB era piuttosto popolare, e così ho deciso di provarlo e scrivere un piccolo logger con traceback. Il nuovo logger consisteva solo in un singolo file Python, che forniva un elenco di bug con opzioni di ordinamento e filtro e una pagina di invio. E sullo sfondo ho iniziato un processo CouchDB. Il nuovo software ha risposto in modo estremamente rapido a tutte le richieste e siamo stati in grado di visualizzare l'enorme quantità di segnalazioni di bug automatiche.

Una cosa interessante è che la soluzione precedente era in esecuzione su un vecchio server dedicato, dove invece il nuovo sito basato su CouchDB era in esecuzione su un'istanza xen condivisa con risorse molto limitate. E non ho nemmeno usato la forza dei negozi di valori-chiave per ridimensionare orizzontalmente. La capacità di CouchDB / Erlang OTP di gestire richieste simultanee senza bloccare nulla era già sufficiente per soddisfare le esigenze.

Ora, il logger CouchDB-traceback scritto rapidamente è ancora in esecuzione ed è un modo utile per esplorare i bug sul sito Web principale. Ad ogni modo, circa una volta al mese il database diventa troppo grande e il processo CouchDB viene interrotto. Ma poi, il comando compact-db di CouchDB riduce di nuovo le dimensioni da diversi GB ad alcuni KB e il database è di nuovo funzionante (forse dovrei considerare di aggiungere un cronjob lì ... 0o).

In breve, CouchDB è stata sicuramente la scelta migliore (o almeno una scelta migliore di MySQL) per questo sottoprogetto e fa bene il suo lavoro.

Il mio attuale progetto in realtà.

Memorizzazione di 18.000 oggetti in una struttura normalizzata: 90.000 righe su 8 tabelle diverse. Ci sono voluti 1 minuto per recuperarli e mapparli sul nostro modello di oggetti Java, ovvero con tutto correttamente indicizzato, ecc.

Memorizzandoli come coppie chiave / valore usando una rappresentazione di testo leggera: 1 tabella, 18.000 righe, 3 secondi per recuperarli tutti e ricostruire gli oggetti Java.

In termini commerciali: la prima opzione non era fattibile. La seconda opzione indica che la nostra app funziona.

Dettagli tecnologici: in esecuzione su MySQL sia per SQL che per NoSQL! Attenersi a MySQL per un buon supporto delle transazioni, prestazioni e comprovata esperienza per non corrompere i dati, ridimensionare abbastanza bene, supporto per il clustering ecc.

Il nostro modello di dati in MySQL ora è solo campi chiave (numeri interi) e il grande campo "valore": sostanzialmente un grande campo TEXT.

Non siamo andati con nessuno dei nuovi giocatori (CouchDB, Cassandra, MongoDB, ecc.) Perché sebbene ognuno di essi offra caratteristiche / prestazioni eccezionali a sé stante, ci sono sempre stati degli svantaggi per le nostre circostanze (ad esempio supporto Java mancante / immaturo).

Ulteriore vantaggio di (ab) utilizzando MySQL - i bit del nostro modello che fanno il lavoro relazionale può essere facilmente collegata ai nostri memorizzare i dati chiave / valore.

Aggiornamento: ecco un esempio di come abbiamo rappresentato il contenuto del testo, non il nostro vero dominio aziendale (non lavoriamo con "prodotti") mentre il mio capo mi sparava, ma trasmette l'idea, incluso l'aspetto ricorsivo (un'entità, qui un prodotto "contenente" altri). Spero che sia chiaro come in una struttura normalizzata potrebbero esserci parecchi tavoli, ad esempio unendo un prodotto alla sua gamma di sapori, quali altri prodotti sono contenuti, ecc.

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

Highscalability.com di Todd Hoff ha molta copertura su NoSQL, inclusi alcuni casi studio.

Il DBMS colonnare Vertica commerciale potrebbe soddisfare i tuoi scopi (anche se supporta SQL): è molto veloce rispetto ai DBMS relazionali tradizionali per le query di analisi. Vedi il recente documento CACM di Stonebraker, et al., Che contrappone Vertica a map-ridurre.

Aggiornamento: E Cassandra ha selezionato Twitter su molti altri, tra cui HBase, Voldemort, MongoDB, MemcacheDB, Redis e HyperTable.

Aggiornamento 2: Rick Cattell ha appena pubblicato un confronto tra diversi sistemi NoSQL negli archivi dati ad alte prestazioni . E la versione di highscalability.com sul documento di Rick è qui .

Abbiamo spostato parte dei nostri dati da mysql a mongodb, non tanto per la scalabilità, ma soprattutto perché si adatta meglio a file e dati non tabulari.

In produzione attualmente archiviamo:

• 25 mila file (60 GB)
• 130 milioni di altri "documenti" (350 GB)

con un fatturato giornaliero di circa 10 GB.

Il database viene distribuito in una configurazione "accoppiata" su due nodi (6x450GB sas raid10) con client apache / wsgi / python utilizzando il mongodb python api (pymongo). L'installazione del disco è probabilmente eccessiva, ma è quello che usiamo per mysql.

A parte alcuni problemi con i threadpool di Pymongo e la natura bloccante del server mongodb, è stata una bella esperienza.

Chiedo scusa per andare contro il tuo testo in grassetto, dal momento che non ho alcuna esperienza diretta, ma questa serie di post sul blog è un buon esempio di risoluzione di un problema con CouchDB.

CouchDB: un caso di studio

In sostanza, l' applicazione textme utilizzava CouchDB per gestire il problema dei dati esplosivi. Hanno scoperto che SQL era troppo lento per gestire grandi quantità di dati di archivio e lo hanno spostato su CouchDB. È una lettura eccellente e discute l'intero processo per capire quali problemi CouchDB potrebbe risolvere e come hanno risolto.

Abbiamo spostato alcuni dei nostri dati che abbiamo usato per archiviare in Postgresql e memorizzati in Redis . Gli archivi di valori chiave sono molto più adatti per l'archiviazione di dati gerarchici di oggetti. È possibile archiviare i dati BLOB molto più rapidamente e con tempi e sforzi di sviluppo molto inferiori rispetto all'utilizzo di un ORM per mappare il BLOB a un RDBMS.

Ho un client open source c # redis che ti consente di archiviare e recuperare qualsiasi oggetto POCO con 1 riga:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Gli archivi di valori chiave sono anche molto più facili da "ridimensionare" in quanto è possibile aggiungere un nuovo server e quindi suddividere il carico in modo uniforme per includere il nuovo server. È importante sottolineare che non esiste un server centrale che limiterà la tua scalabilità. (anche se avrai comunque bisogno di una strategia per un hashing coerente per distribuire le tue richieste).

Considero Redis come un "file di testo gestito" sugli steroidi che fornisce un accesso rapido, simultaneo e atomico a più client, quindi tutto ciò che ho usato per usare un file di testo o un database incorporato per ora uso Redis. ad es. per ottenere un registro degli errori di rolling combinato in tempo reale per tutti i nostri servizi (che notoriamente è stato un compito difficile per noi), ora viene realizzato con solo un paio di righe semplicemente anticipando l'errore a un elenco lato server Redis e quindi tagliando l'elenco in modo da conservare solo gli ultimi 1000, ad esempio:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

Non ho esperienze di prima mano., Ma ho trovato questo post sul blog abbastanza interessante.

Trovo lo sforzo di mappare gli oggetti del dominio software (ad es. ASalesOrder, aCustomer ...) al database relazionale bidimensionale (righe e colonne) richiede un sacco di codice per salvare / aggiornare e quindi di nuovo per creare un'istanza di un'istanza di oggetto di dominio da più tabelle . Per non parlare dell'hit di prestazioni di avere tutti quei join, tutti quei dischi leggono ... solo per visualizzare / manipolare un oggetto di dominio come un ordine cliente o un record cliente.

Siamo passati a Object Database Management Systems (ODBMS). Sono al di là delle capacità dei sistemi noSQL elencati. GemStone / S (per Smalltalk) ne è un esempio. Esistono altre soluzioni ODBMS che dispongono di driver per molte lingue. Un vantaggio chiave per gli sviluppatori, la gerarchia di classi è automaticamente lo schema del database, le sottoclassi e tutto il resto. Basta usare il linguaggio orientato agli oggetti per rendere gli oggetti persistenti nel database. I sistemi ODBMS forniscono un'integrità delle transazioni a livello ACID, quindi funzionerebbero anche nei sistemi finanziari.

Sono passato da MySQL (InnoDB) a Cassandra per un sistema M2M, che in sostanza memorizza serie temporali di sensori per ciascun dispositivo. Ogni dato è indicizzato da (device_id, date) e (device_id, type_of_sensor, date). La versione di MySQL conteneva 20 milioni di righe.

MySQL:

• Installazione in sincronizzazione master-master. Pochi problemi sono apparsi sulla perdita di sincronizzazione . È stato stressante e soprattutto all'inizio potrebbero essere necessarie ore per risolvere.
• Il tempo di inserimento non è stato un problema, ma le query richiedevano sempre più memoria man mano che i dati crescevano. Il problema è che gli indici sono considerati nel loro insieme. Nel mio caso, stavo usando solo una parte molto sottile degli indici che erano necessari per caricare in memoria (solo pochi percento dei dispositivi erano frequentemente monitorati ed era sui dati più recenti).
• È stato difficile eseguire il backup . Rsync non è in grado di eseguire backup rapidi su file di tabelle InnoDB di grandi dimensioni.
• Divenne rapidamente chiaro che non era possibile aggiornare lo schema delle tabelle pesanti , poiché impiegava troppo tempo (ore).
• L'importazione dei dati ha richiesto ore (anche alla fine dell'indicizzazione). Il miglior piano di salvataggio consisteva nel conservare sempre alcune copie del database (file di dati + registri).
• Passare da una società di hosting all'altra è stato davvero un grosso problema . La replica doveva essere gestita con molta attenzione.

Cassandra:

• Ancora più facile da installare rispetto a MySQL.
• Richiede molta RAM. Un'istanza da 2 GB non poteva farla funzionare nelle prime versioni, ora può funzionare su un'istanza da 1 GB ma non è un'idea (troppi flushing di dati). Dare 8 GB è stato sufficiente nel nostro caso.
• Una volta compreso come organizzare i dati, la memorizzazione è semplice. La richiesta è un po 'più complessa. Ma una volta che lo aggiri, è molto veloce (non puoi davvero fare errori a meno che tu non voglia davvero).
• Se il passaggio precedente è stato eseguito correttamente, lo è e rimane super veloce.
• Sembra quasi che i dati siano organizzati per il backup. Ogni nuovo dato viene aggiunto come nuovo file. Personalmente, ma non è una buona cosa, svuoto i dati ogni notte e prima di ogni arresto (di solito per l'aggiornamento) in modo che il ripristino richieda meno tempo, perché abbiamo meno registri da leggere. Non crea molti file se sono compattati.
• L'importazione dei dati è velocissima. E più host hai, più velocemente. L'esportazione e l'importazione di gigabyte di dati non è più un problema.
• Non avere uno schema è una cosa molto interessante perché puoi far evolvere i tuoi dati per soddisfare le tue esigenze. Ciò potrebbe significare avere versioni diverse dei tuoi dati contemporaneamente sulla stessa famiglia di colonne.
• Aggiungere un host è stato facile (non veloce però) ma non l'ho fatto su una configurazione multi-datacenter.

Nota: ho anche usato elasticsearch (documento orientato basato su lucene) e penso che dovrebbe essere considerato come un database NoSQL. È distribuito, affidabile e spesso veloce (alcune query complesse possono funzionare piuttosto male).

Io non. Vorrei utilizzare un archivio di valori-chiave semplice e gratuito che posso chiamare in corso, ma tale cosa non esiste sulla piattaforma Windows. Ora uso Sqlite ma vorrei usare qualcosa come Tokyo Cabinet. BerkeleyDB ha "problemi" di licenza.

Tuttavia, se si desidera utilizzare il sistema operativo Windows, la scelta dei database NoSQL è limitata. E non c'è sempre un provider C #

Ho provato MongoDB ed è stato 40 volte più veloce di Sqlite, quindi forse dovrei usarlo. Ma spero ancora per una semplice soluzione in corso.

Ho usato redis per archiviare i messaggi di registrazione su macchine. È stato molto facile da implementare e molto utile. Redis è davvero incredibile

Abbiamo sostituito un database Postgres con un database di documenti CouchDB perché non avere uno schema fisso è stato un grande vantaggio per noi. Ogni documento ha un numero variabile di indici utilizzati per accedere a quel documento.

Ho usato Couchbase in passato e abbiamo riscontrato problemi di riequilibrio e molti altri problemi. Attualmente sto usando Redis in diversi progetti di produzione. Sto usando redislabs.com che è un servizio gestito per Redis che si occupa di ridimensionare i cluster Redis. Ho pubblicato un video sulla persistenza degli oggetti sul mio blog all'indirizzo http://thomasjaeger.wordpress.com che mostra come utilizzare Redis in un modello di provider e come archiviare gli oggetti C # in Redis. Guarda.

Vorrei incoraggiare chiunque leggesse questo a provare Couchbase ancora una volta ora che 3.0 è fuori dalla porta. Ci sono oltre 200 nuove funzionalità per i principianti. Le prestazioni, la disponibilità, la scalabilità e le semplici funzioni di gestione di Couchbase Server rendono un database estremamente flessibile e altamente disponibile. L'interfaccia utente di gestione è integrata e le API rilevano automaticamente i nodi del cluster, quindi non è necessario un bilanciamento del carico dall'applicazione al database. Anche se al momento non abbiamo un servizio gestito, puoi eseguire couchbase su cose come AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers come CloudSoft e molto altro. Per quanto riguarda il riequilibrio, dipende da ciò a cui ti riferisci, ma Couchbase non riequilibra automaticamente dopo un errore del nodo, come previsto, ma un amministratore potrebbe impostare il failover automatico per il primo errore del nodo e utilizzando le nostre API è inoltre possibile ottenere l'accesso ai vbucket di replica per la lettura prima di renderli attivi o utilizzando RestAPI è possibile imporre un failover da uno strumento di monitoraggio. Questo è un caso speciale ma è possibile farlo.

Tendiamo a non riequilibrare praticamente in qualsiasi modalità a meno che il nodo non sia completamente offline e non ritorni più o un nuovo nodo sia pronto per essere bilanciato automaticamente. Ecco un paio di guide per aiutare chiunque sia interessato a vedere in cosa consiste uno dei database NoSQL più performanti.

1. Couchbase Server 3.0
2. Guida all'amministrazione
3. API REST
4. Guide per gli sviluppatori

Infine, ti incoraggio anche a dare un'occhiata a N1QL per le query distribuite:

1. Tutorial N1QL
2. Guida N1QL

Grazie per aver letto e fate sapere a me o agli altri se avete bisogno di più aiuto!

Austin

Ho usato Vertica in passato: si basa sulla compressione colonnare e accelera le letture del disco e riduce le esigenze di archiviazione per sfruttare al meglio il tuo hardware. Carichi di dati più rapidi e una maggiore concorrenza consentono di fornire dati di analisi a più utenti con una latenza minima.

In precedenza, stavamo interrogando il database Oracle con miliardi di record e le prestazioni erano molto non ottimali. L'esecuzione delle query ha richiesto da 8 a 12 secondi, anche dopo l'ottimizzazione con SSD. Pertanto, abbiamo sentito la necessità di utilizzare un database ottimizzato per la lettura e ottimizzato per la lettura più veloce. Con Vertica Clusters dietro il livello di servizio lean, potremmo eseguire API con prestazioni inferiori al secondo.

Vertica archivia i dati in proiezioni in un formato che ottimizza l'esecuzione della query. Analogamente alle viste materializzate, le proiezioni memorizzano i set di risultati su disco o SSD anziché calcolarli ogni volta che vengono utilizzati in una query. Le proiezioni offrono i seguenti vantaggi:

1. Comprimi e codifica i dati per ridurre lo spazio di archiviazione.
2. Semplifica la distribuzione attraverso il cluster di database.
3. Fornire elevata disponibilità e ripristino.

Vertica ottimizza il database distribuendo i dati attraverso il cluster utilizzando la segmentazione.

1. La segmentazione inserisce una porzione di dati su un nodo.
2. Distribuisce uniformemente i dati su tutti i nodi. Pertanto, ciascun nodo esegue una parte del processo di query.
3. La query viene eseguita sul cluster e ogni nodo riceve il piano di query.
4. I risultati delle query sono aggregati e utilizzati per creare l'output.

Per ulteriori informazioni, consultare la documentazione Vertica @ https://www.vertica.com/knowledgebase/