Ruby On Rails / Merb come frontend per un'app di miliardi di record

Question

Sto cercando una soluzione di back-end per un'applicazione scritta in Ruby on Rails o Merb per gestire i dati con diversi miliardi di record. Ho la sensazione che dovrei andare con un modello distribuito e al momento ho guardato

HBase con Hadoop

Couchdb

Problemi con la soluzione HBase come la vedo io - il supporto per ruby ??non è molto forte e Couchdb non ha ancora raggiunto la versione 1.0.

Hai suggerimenti su cosa useresti per una così grande quantità di dati?

I dati richiederanno importazioni piuttosto veloci a volte di 30-40 Mb contemporaneamente, ma le importazioni arriveranno in pezzi. Quindi ~ il 95% delle volte i dati saranno di sola lettura.

Answer 1

A seconda dell'effettivo utilizzo dei dati, MySQL o Postgres dovrebbero essere in grado di gestire un paio di miliardi di record sull'hardware giusto. Se si dispone di un volume particolarmente elevato di richieste, entrambi questi database possono essere replicati su più server (e la replica in lettura è abbastanza facile da configurare (rispetto alla replica multipla master / write).

Il grande vantaggio dell'utilizzo di un RDBMS con Rails o Merb è l'accesso a tutti gli eccellenti strumenti di supporto per l'accesso a questi tipi di database.

Il mio consiglio è di profilare effettivamente i tuoi dati in un paio di questi sistemi e di prenderli da lì.

Answer 2

Esistono diverse soluzioni che le persone hanno utilizzato. Nella mia esperienza, dipende molto di più dai tuoi schemi di utilizzo relativi a tali dati e non dal semplice numero di righe per tabella.

Ad esempio, " Quanti inserimenti / aggiornamenti si verificano al secondo. " Domande come queste giocheranno nella tua decisione su quale soluzione di database back-end sceglierai.

Prendi ad esempio Google: in realtà non esisteva una soluzione di archiviazione / ricerca che soddisfacesse le loro esigenze, quindi ne crearono una basata su un modello di mappa / riduzione.

Answer 3

Un avvertimento su HBase e altri progetti di quel tipo (non so nulla di CouchDB - penso non è proprio un db, ma solo un archivio di valori-chiave):

1. Hbase non è ottimizzato per la velocità; è ottimizzato per la scalabilità. Se la velocità di risposta è assolutamente un problema, esegui alcune prove di concetto prima di impegnarti in questo percorso.
2. Hbase non supporta i join. Se stai usando ActiveRecord e hai più di una relazione .. bene puoi vedere dove sta andando.

Il progetto Hive, anch'esso basato su Hadoop, supporta i join; così fa Pig (ma non è proprio sql). Il punto 1 si applica ad entrambi. Sono pensati per attività di elaborazione di dati pesanti, non per il tipo di elaborazione che probabilmente eseguirai con Rails.

Se si desidera la scalabilità per un'app Web, in pratica l'unica strategia che funziona è quella di partizionare i dati e fare il più possibile per garantire che le partizioni siano isolate (non è necessario parlarsi). Questo è un po 'complicato con Rails, dato che presume che ci sia un database centrale. Potrebbero esserci stati miglioramenti su questo fronte da quando ho esaminato il problema circa un anno e mezzo fa. Se è possibile partizionare i dati, è possibile ridimensionare orizzontalmente in modo abbastanza ampio. Una singola macchina MySQL può gestire alcuni milioni di righe (PostgreSQL può probabilmente ridimensionarsi su un numero maggiore di righe ma potrebbe funzionare un po 'più lentamente).

Un'altra strategia che funziona è avere un master-slave impostato, in cui tutte le scritture vengono eseguite dal master e le letture sono condivise tra gli slave (e possibilmente il master). Ovviamente questo deve essere fatto abbastanza attentamente! Supponendo un elevato rapporto lettura / scrittura, questo può ridimensionarsi abbastanza bene.

Se la tua organizzazione ha delle tasche profonde, controlla cosa hanno da offrire Vertica, AsterData e Greenplum.

Answer 4

Il backend dipenderà dai dati e da come i dati saranno accessibili.

Ma per l'ORM molto probabilmente userei DataMapper e scrivo un adattatore DataObjects personalizzato per arrivare a qualunque backend tu scelga.

Answer 5

Non sono sicuro di cosa abbia a che fare CouchDB con 1.0. Consiglierei di fare alcuni test con esso (basta generare un miliardo di documenti casuali) e vedere se reggerà. Direi che lo farà, nonostante non abbia un numero di versione specifico.

CouchDB ti aiuterà molto quando si tratta di partizionare / condividere i tuoi dati e simili, sembra che potrebbe adattarsi al tuo progetto, specialmente se il tuo formato dei dati potrebbe cambiare in futuro (aggiunta o rimozione di campi) dal momento che i database CouchDB non ha schema.

Ci sono molte ottimizzazioni in CouchDB anche per le app pesanti e, in base alla mia esperienza con essa, è dove brilla davvero.