Scegliere una tecnologia di database

Question

Ci stiamo proponendo di costruire una piattaforma online (API, server, dati, Wahoo!).Per contesto, immagina di dover costruire qualcosa come Twitter, ma con i commenti (tweet) organizzati attorno a un evento dal vivo.Le informazioni sull'evento dal vivo stesso devono essere fornite ai clienti nel modo più rapido e coerente possibile, mentre i commenti sull'evento possono probabilmente attendere un po' più a lungo per essere consegnati.Saremo molto carichi di letture al termine dell'evento dal vivo.

La scalabilità è molto importante.Vogliamo iniziare noleggiando porzioni VPS e scalare da lì.Sono un grande fan del cloud e vorrei restarci il più a lungo possibile.Probabilmente useremo Ruby.

Sono convinto di voler provare un archivio documenti invece di un RDBMS.Mi piace l'idea di un'archiviazione senza schema e le promesse di una scalabilità più semplice concentrandosi sul valore-chiave.

Il problema è che non so quale sia la tecnologia più appropriata per la nostra piattaforma.Ho esaminato Couch, Mongo, Tokyo Cabinet, Cassandra e un RDBMS con documenti confusi.Qualche aiuto per scegliere lo strumento giusto per questo particolare lavoro?

Answer 1

Controlla il confronto delle alternative NO SQL di B.J. Clark.

La scalabilità è molto importante.

Quindi devi considerare gli estratti dal suo blog:

1. Gabinetto di Tokyo: non è in scala
2. Redis: non scalabile
3. Progetto Voldemort - bilancia
4. MongoDB - limitato (è stato implementato lo sharding)
5. Cassandra - squame
6. Amazon S3 - bilancia
7. Divano - Non scala (Raggruppamento e replica)
8. MySQL: non scalabile

E considera HyperTable.Questo è anche un serio contendente tra le alternative No-SQL.È un'implementazione open source del concetto BigTable di Google.Credo che si adatti bene perché è ampiamente utilizzato dal motore di ricerca cinese Baidu e dal portale di intrattenimento Rediff.

Stavi dicendo:

Le informazioni sull'evento dal vivo stesso devono essere consegnate ai clienti il ​​più velocemente e coerentemente possibile, mentre i commenti sull'evento possono probabilmente aspettare un po 'di più per essere consegnati.Saremo pesanti dopo la fine dell'evento dal vivo.

Questo è qualcosa di simile all'approccio di Twitter.Anche la scelta del linguaggio di programmazione è molto importante, perché inizialmente Twitter ha scelto Ruby per la consegna dei messaggi di back-end, ma stavano dicendo non è una scelta corretta e hanno spostato l'intero sistema di consegna dei messaggi su Scala lingua.

Stanno ancora usando Ruby per il loro front-end.Se desideri utilizzare un sistema altamente affidabile e tollerante ai guasti che sia adatto per ambienti scalabili, dovresti prendere in considerazione Scala O Erlang.

Answer 2

Ramesh ha una buona sintesi. Vorrei aggiungere che Cassandra ha un modello di dati più ricco di cloni di vaniglia Dynamo (come Voldemort o Dynomite): le righe con nome, colonne ordinate e non solo chiave / valore. Cassandra è utilizzato da Twitter, Mahalo, Ooyala, SimpleGeo, WebEx, e altri ( http://n2.nabble.com/Cassandra-users-survey-td4040068.html ), almeno alcuni dei quali sono in esecuzione cluster Cassandra su server cloud EC2 o Rackspace.

Answer 3

Se si desidera ridimensionare in senso orizzontale (distribuire i dati su più di un nodo) si deve prendere il teorema PAC in considerazione.

http://www.julianbrowne.com/article/viewer/brewers -Cap-teorema

Non è roba facile, ma si deve scegliere, c'è sempre un qualche tipo di compromesso.