strategia di persistenza per bassa latenza di lettura e scrittura

Question

sto costruendo un'applicazione che include una funzione per milioni di tag di massa di record, più o meno in modo interattivo. L'interazione con l'utente è molto simile a Gmail dove gli utenti possono contrassegnare singole e-mail, o tag di massa di grandi quantità di messaggi di posta elettronica. Ho anche bisogno di accesso in lettura veloce per queste appartenenze tag come bene, e dove il modello di lettura è più o meno casuale.

In questo momento stiamo utilizzando Mysql e inserendo una riga per ogni coppia di tag-documento. Scrivendo milioni di righe a MySQL vuole un po '(alta I / O), anche con inserimenti di massa e l'ottimizzazione pesante. Abbiamo bisogno di questo per essere un processo interattivo, non un processo batch.

Per i dati che stiamo memorizzazione e la lettura, la consistenza e la disponibilità dei dati non sono importanti quanto le prestazioni e la scalabilità. Quindi, in caso di guasto del sistema, mentre le operazioni di scrittura sono in corso, posso affrontare con una certa perdita di dati. Tuttavia, i dati devono sicuramente essere persistito storage secondario a un certo punto.

Quindi, per riassumere, qui sono i requisiti:

• di massa a bassa latenza scrive potenzialmente decine di milioni di record
• I dati devono essere persistito in qualche modo
• Bassa latenza casuale legge
• scrive durevoli non richiesto
• coerenza eventuale va bene

Ecco alcune soluzioni che ho guardato:

• Scrivi dietro le cache (Terracotta, GigaSpaces, coerenza) in cui i record vengono scritti alla memoria e drenati al database in modo asincrono. Questi mi spaventano un po ', perché sembrano aggiungere una certa quantità di complessità al app che vorrei evitare.
• altamente scalabile negozi chiave-valore, come MongoDB, HBase, Tokyo Tyrant

Answer 1

Se avete il budget per utilizzare coerenza per questo, vi consiglio vivamente di farlo. V'è il supporto diretto per write-behind, eventuale comportamento coerenza in Coherence ed è molto sopravvivere sia un'interruzione di database e coerenza interruzioni nodi del cluster (se si utilizza> = 3 nodi di coerenza sulla JVM separate, preferibilmente su host separati). Ho implementato questo per fare grandi volumi di CRM per il sito di e-commerce di una società Fortune 100 di e funziona fantasticamente.

Uno degli aspetti migliori di questa architettura è che si scrive il codice dell'applicazione Java come se nessuno del comportamento write-behind stavano prendendo posto, e poi collegare la topologia Coerenza e configurazione che fa accadere. Se è necessario modificare il comportamento o la topologia di coerenza in seguito, non è necessario alcun cambiamento nella vostra applicazione. So che ci sono probabilmente una manciata di modi ragionevoli per fare questo, ma questo comportamento è direttamente supportato in Coherence, piuttosto che dover inventare o mano-roll un modo di farlo.

Per fare un punto davvero bene - la vostra preoccupazione circa l'aggiunta di complessità delle applicazioni è un buon compromesso. Con coerenza, è sufficiente scrivere gli aggiornamenti alla cache (o se si sta usando Hibernate può essere il fornitore di cache L2). A seconda della configurazione coerenza e la topologia, si ha la possibilità di distribuire l'applicazione per utilizzare write-behind, distribuiti, cache. Quindi, l'applicazione non è più complesso (e, francamente inconsapevoli) a causa delle caratteristiche della cache.

Infine, ho implementato la soluzione menzionata sopra da 2005-2007 quando la coerenza è stata fatta da Tangosol e avevano il miglior supporto possibile. Non sono sicuro di come stanno le cose ora sotto Oracle -. Si spera ancora buono

Answer 2

Ho lavorato su un grande progetto che ha utilizzato asincrona scrive althoguh in quel caso era solo a mano scritto usando thread in background. Si potrebbe anche implementare qualcosa di simile scaricando il processo di scrittura db ad una coda JMS.

Una cosa che sicuramente accelerare db scrive è quello di fare loro in lotti. aggiornamenti batch JDBC possono essere ordini di grandezza più veloce di singole operazioni di scrittura, e se si sta facendo in modo asincrono li si può semplicemente scrivere loro 500 alla volta.

Answer 3

A seconda di come i dati sono organizzati forse si sarebbe in grado di utilizzare sharding , se la latenza di lettura non è sufficientemente bassa si può anche tenta di aggiungere il caching. Memcache è una soluzione popolare.

Answer 4

Berkeley DB ha una tabella di hash basato su disco molto ad alte prestazioni che supporta le transazioni, e si integra con un ambiente Java EE se avete bisogno di questo. Se siete in grado di modellare i dati come coppie chiave / valore, questa può essere una soluzione molto scalabile.

http://www.oracle.com/technology /products/berkeley-db/je/index.html

(Nota: Oracle ha acquistato Berkeley DB circa 5-10 anni fa, il prodotto originale è stato intorno per 15-20 anni).