La production de Cassandra est-elle prête pour Ruby on Rails?

Question

Je travaille sur un projet qui envisage d'utiliser Cassandra comme base de données. Nous aimerions éventuellement migrer vers Cassandra même si nous utilisons MySQL pour commencer, étant donné son évolutivité. Je sais que de grandes entreprises comme Facebook, Digg et récemment Twitter utilisent Cassandra, mais je ne crois pas qu'aucun de ces sites ne fonctionne sur Rails. Ma question est de savoir s'il est possible ou non d'utiliser Cassandra en utilisant Ruby on Rails. Points à prendre en compte:

1. Nous dépendons fortement de la gemme Authlogic. Est-ce que passer à Cassandra affecterait le fonctionnement?
2. Y a-t-il des clients Ruby matures pour Cassandra? En regardant Github, il semble que fauna's client (now twitters's client) est le plus mature. Quelqu'un at-il eu une expérience de production avec?

Appréciez toutes les astuces.

Answer 1

Twitter est courant sur la plupart des rails avant. Le client de Fauna est en fait construit et publié par Twitter, vous pouvez donc être certain qu'il est à jour et stable sur de grandes charges de travail. Regarder l'histoire des commits montre qu'il y a de fréquentes améliorations, ce qui est génial.

Probablement Authlogic devrait être personnalisé pour fonctionner correctement avec Cassandra. En particulier, il semble fournir certaines méthodes basées sur named_scope et des données relationnelles.

Il semble que quelqu'un ait construit un plugin pour le support de DataMapper dans Authlogic: http://twitter.com/collintmiller/statuses/2064046718. Vous pouvez peut-être utiliser cela comme point de départ pour le rendre compatible avec Cassandra.

Bonne chance!

Answer 2

Je ne pense pas que commencer avec MySQL, puis passer à Cassandra est une bonne idée.

Cassandra est une solution NoSQL, tandis que MySQL est une base de données SQL "classique".

Cela signifie que vos modèles seraient différents.

Si vous démarrez avec MySQL, vous devrez compter sur ActiveRecord pour créer vos modèles. Si vous changez ensuite pour Cassandra, vous devrez changer tous vos modèles en un middleware compatible NoSQL (tel que BigRecord). Cela ne signifie pas seulement changer vos modèles, mais aussi les contrôleurs qui les utilisent (puisque leur interface serait différente). Cela dit, Cassandra et autres sont supposés être utilisés sur des applications très exigeantes - comme Twitter.

Le reste des applications Web sont moins intenses - êtes-vous certain de toujours avoir besoin de Cassandra?

PostgreSQL, et une base de données bien conçue, est juste assez bon 98% du temps.

Answer 3

Il existe également http://github.com/NZKoz/cassandra_object, que IIANM construit au-dessus du client fauna. "Cassandra Object fournit une API sympa pour travailler avec Cassandra.Les CassandraObjects sont pour la plupart de type canard compatibles avec les objets ActiveRecord donc la plupart de votre code de contrôleur devrait fonctionner ... Utilisez ceci en production seulement si vous cherchez à aider au développement , il y a un tas d'aspérités en ce moment. "

Answer 4

Je recherche Cassandra, MongoDB et CouchDB pour le moment.

Une façon de déterminer quel est le support de développeur le plus important consiste à vérifier le nombre de visionneuses du projet github le mieux noté pour chacune. Au moins comme une estimation approximative.

En ce moment, il est

852 - MongoDB http://github.com/jnunemaker/mongomapper

544 - CouchDB http://github.com/jchris/couchrest

178 - Cassandra http://github.com/fauna/cassandra

Bien que, je dois dire avec un groupe de haut profil sites (Twitter, Digg, Reddit, etc) ont récemment annoncé qu'ils déménagent à Cassandra, c'est un grand ote de confiance pour eux.

Mongo semble avoir la meilleure et la meilleure documentation à ce jour. Leur auto-sharding est toujours en alpha bien que son échelle reste encore à voir.

Je commence tout juste à apprendre à propos de toutes ces choses, alors si d'autres ont des idées, partagez-les.

Answer 5

Si vous changez ensuite à Cassandra, vous devrez changer tous vos modèles à un NoSQL

Ce n'est pas vrai du tout. Si vous avez programmé de telle manière que votre base de données MySQL fasse des charges de jointures, alors oui, vous pourriez avoir un problème. Nous avons évité autant que possible les jointures lorsque nous avons commencé la route MySQL. Ensuite, quand nous avons commencé à migrer vers Casandra, c'était assez facile, nous l'avons fait avec un seul modèle au début. Ensuite, dites 4 modèles en une fois. Etc. Fonctionne bien. En fait, quand vous lisez l'interview avec twitter, vous remarquerez qu'ils ont couru MySQL et Casandra en parallèle pour le même modèle pendant un certain temps: http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king. En ce qui concerne Authlogic, vous pouvez conserver cette partie dans mySQL aussi longtemps que vous le souhaitez, mais gardez-la avec vos données Cassandra.