Choisir une technologie de base de données

Question

Nous mettons à construire une plate-forme en ligne (API, serveurs, données, Wahoo!). Pour le contexte, imaginez que nous avons besoin de construire quelque chose comme Twitter, mais avec les commentaires (tweets) organisés autour d'un événement en direct. Informations sur l'événement en direct lui-même doit être livré aux clients aussi rapidement et de manière cohérente que possible, tandis que des commentaires sur l'événement peuvent probablement attendre un peu plus longtemps à livrer. Nous allons lire lourds après l'événement en direct se termine.

Évolutivité est très important. Nous voulons commencer la location de tranches de VPS et échelle à partir de là. Je suis un grand fan du nuage, et je voudrais y rester aussi longtemps que possible. Nous allons probablement utiliser rubis.

Je suis convaincu que je veux essayer un document magasin au lieu d'un SGBDR. J'aime l'idée de stockage de schéma et moins les promesses d'évolutivité plus facile en se concentrant sur la valeur clé.

Le problème est que je ne sais pas quelle est la technologie la plus appropriée pour notre plate-forme. Je l'ai regardé Couch, Mongo, Tokyo Cabinet, Cassandra et un SGBDR avec des documents blobbed. Toute aide de choisir le bon outil pour ce travail particulier?

Answer 1

Voir NO alternatives SQL comparaison par BJ Clark.

  

Évolutivité est très important.

Ensuite, vous devez tenir compte des extraits de son blog:

1. Tokyo Cabinet - Ne pas l'échelle
2. Redis - n'échelle
3. Projet Voldemort - échelles
4. MongoDB - limted (sharding est été mis en œuvre)
5. Cassandra - échelles
6. Amazon S3 - échelles
7. Couch - Ne pas l'échelle ( Clustering et la réplication)
8. MySQL - n'échelle

HyperTable . Ceci est également un concurrent sérieux dans des alternatives non-SQL. Il est une implémentation open source du concept BigTable de Google. Je crois qu'il adapte bien parce qu'il est largement utilisé par le moteur de recherche chinois Baidu et le portail de divertissement Rediff.

Vous disiez:

  

Informations sur l'événement en direct   lui-même doit être remis aux clients comme   rapide et cohérente que possible,   tandis que des commentaires sur l'événement peut   probablement attendre un peu plus pour être   livré. Nous allons lire lourds après   l'événement en direct se termine.

Ceci est quelque chose comme l'approche de Twitter. Votre sélection de langage de programmation est également très important, parce que Twitter est d'abord allé avec Ruby pour la livraison de messages back-end mais langage Scala.

Ils utilisent encore Ruby pour leur front-end. Si vous voulez aller avec un système tolérant aux pannes très fiable qui est bien adapté pour les environnements évolutifs, alors vous devriez envisager Scala ou Erlang .

Answer 2

Ramesh a un bon résumé. Je voudrais ajouter que Cassandra a un modèle de données plus riche que les clones de vanille Dynamo (comme Voldemort ou Dynomite): les lignes avec des colonnes nommées, triées plutôt que juste clé / valeur. Cassandra est utilisé par Twitter, Mahalo, Ooyala, SimpleGeo, WebEx, et d'autres ( http://n2.nabble.com/Cassandra-users-survey-td4040068.html ), au moins certaines d'entre elles sont en cours d'exécution sur les clusters Cassandra serveurs cloud EC2 ou Rackspace.

Answer 3

Si vous voulez à l'échelle horizontale (distribuer vos données sur plus d'un noeud), vous devez prendre le théorème de la PAC en compte.

http://www.julianbrowne.com/article/viewer/brewers -Cap-théorème

Il est facile, mais pas des choses que vous avez à choisir, il y a toujours une sorte de compromis.