Redis, CouchDB ou Cassandra?

Question

Quelles sont les forces et les faiblesses des différentes bases de données NoSQL disponibles?

En particulier, il semble que Redis soit faible en matière de répartition de la charge en écriture sur plusieurs serveurs. Est-ce le cas? Est-ce un gros problème? Quelle doit être la taille d'un service avant que cela puisse poser un problème important?

Answer 1

Les forces et les faiblesses des bases de données NoSQL (et aussi des bases de données SQL) est très dépendante de votre cas d'utilisation. Pour les très grands projets, la performance est roi; mais pour la marque de nouveaux projets ou des projets où le temps et les ressources sont limités, de simplicité et de temps-à-marché sont probablement les plus importantes. Pour enseigner vous-même (élargir votre point de vue, de devenir meilleur, plus précieux programmeur), peut-être la chose la plus importante est simple, solide concepts fondamentaux.

Quel type de projet vous avez à l'esprit?

Certaines des forces et des faiblesses, du haut de ma tête:

• Redis
  • Très simple clé-valeur "global variable serveur"
  • Très simple (certains diraient "non-existant") le système de requête
  • Facilement le plus rapide dans cette liste
  • Les Transactions
  • Jeu de données doivent être stockées en mémoire
  • Immatures de clustering, avec avenir flou (je suis sûr que ça va être génial, mais c'est pas encore décidé.)
• Cassandra
  • Sans doute le plus l'impulsion communautaire de la BigTable-comme les bases de données
  • Probablement la méthode la plus simple de cette liste à gérer en gros/clusters en croissance
  • Soutien pour le map/reduce, bon pour analytics, entrepôt de données
  • MUlti-centre de données de réplication
  • Réglage de la cohérence et de la disponibilité
  • Aucun point de défaillance unique
  • Vous devez savoir quelles requêtes vous sera exécuté dès le début du projet, afin de préparer la forme des données et des index
• CouchDB
  • Mains vers le bas le meilleur de la synchronisation (réplication) le soutien, l'appui, maître/esclave, maître/master, et plus exotiques architectures
  • Le protocole HTTP, les navigateurs et les applications peuvent interagir directement avec les DB partiellement ou entièrement. (Synchronisation est également fait sur HTTP)
  • Après une courte courbe d'apprentissage, assez sophistiqué système de requête à l'aide de Javascript et de map/reduce
  • Cluster (pas de SPOF, réglage de la cohérence et de la disponibilité) est un important fourche (BigCouch). Il sera probablement de fusion dans le Canapé, mais il n'y a pas de feuille de route.
  • De même, le clustering et multi-centre de données sont théoriquement possibles (les "exotiques", chose que j'ai mentionné), mais vous devez écrire tout ce que l'outillage-vous en ce moment.
  • Ajouter uniquement le format de fichier (les deux bases de données et les index) consomme disque étonnamment rapidement, et vous devez exécuter manuellement la compaction du sol (aspirateur) qui fait une copie complète de tous les enregistrements dans la base de données. La même chose est requis pour chaque fichier d'index. Encore une fois, vous devez être votre propre toolsmith.

Answer 2

Jetez un coup d'oeil à http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis Il fait un bon travail en résumant la raison pour laquelle vous utiliseriez l'une plutôt que l'autre.