Le passage de MySQL à Cassandra - Avantages / inconvénients?
https://stackoverflow.com/questions/2332113
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Pour un peu de fond - cette question a trait à un projet en cours d'exécution sur une seule petite instance EC2, et est sur le point de migrer vers un moyen. Les principaux composants sont Django, MySQL et un grand nombre d'outils d'analyse personnalisés écrits en Python et Java, qui font la lourde levage. La même machine est en cours d'exécution Apache ainsi.
Le modèle de données se présente comme suit - une grande quantité de données en temps réel est disponible en flux continu à partir de divers capteurs en réseau, et idéalement, je voudrais établir une approche à long sondage plutôt que le sondage actuel toutes les approches de 15 minutes ( une limitation de calculer les statistiques et l'écriture dans la base de données elle-même). Une fois que les données arrive, je stocke la version brute en MySQL, que les outils d'analyse de ces données perdent, et les statistiques de magasin dans un autre quelques tables. Tout cela est rendu en utilisant Django.
caractéristiques relationnelles je aurais besoin -
- Trier par [SliceRange dans l'API de Cassandra semble satisy ce]
- Groupe par
- les relations entre ManyToMany plusieurs tables [Cassandra SuperColumns semblent bien faire pour un à plusieurs]
- Sphinx cela me donne un moteur texte complet agréable, donc ce une nécessité aussi. [Sur Cassandra, le projet Lucandra semble répondre à ce besoin]
Mon problème majeur est que lit les données sont extrêmement lentes (et les écritures sont pas non plus chaud). Je ne veux pas jeter beaucoup d'argent et de matériel à ce moment, et je préfère quelque chose qui peut facilement évoluer avec le temps. MySQL est mise à l'échelle Verticalement pas anodin en ce sens (ou pas cher).
Donc, essentiellement, après avoir lu beaucoup de choses sur NoSQL et expérimenté des choses comme MongoDB, Cassandra et Voldemort, mes questions sont,
-
Sur une instance EC2 moyen, gagnerais-je aucun avantage en lecture / écriture par le passage à quelque chose comme Cassandra ? Cet article (pdf) semble certainement suggérer que. À l'heure actuelle, je dirais que quelques centaines par minute serait écrit la norme. Pour lit - puisque les données change toutes les 5 minutes, l'invalidation du cache doit se produire assez rapidement. À un certain moment, il devrait être capable de gérer un grand nombre d'utilisateurs simultanés ainsi. La performance de l'application se fait actuellement tué sur MySQL fait quelques rejoint sur de grandes tables, même si les index sont créés - quelque chose à l'ordre de 32k lignes prend plus d'une minute pour rendre. (Cela peut être un artefact de EC2 E / S virtualisés ainsi). Taille des tables est environ 4-5 millions de lignes, et il y a environ 5 ces tables.
-
Tout le monde parle de l'utilisation Cassandra sur plusieurs nœuds, étant donné le théorème de la PAC et la cohérence éventuelle. Mais, pour un projet qui commence juste à se développer, est-il logique de déployer un serveur cassandra un node ? Y a-t-il des mises en garde? Par exemple, peut-il remplacer MySQL comme backend pour Django? [Est-ce recommandé?]
-
Si je décalage, je suppose que je vais devoir réécrire une partie de l'application pour faire beaucoup plus « administrivia » depuis que je devais faire plusieurs recherches pour aller chercher des lignes.
-
Ne serait-il logique d'utiliser simplement MySQL comme un magasin de valeur clé plutôt que d'un moteur relationnel, et aller avec ça? De cette façon, je pourrais utiliser un grand nombre d'API stables disponibles, ainsi qu'un moteur stable (et au besoin relationnel vais). (Après de Friendfeed Brett Taylor sur ce point - http://bret.appspot.com/ entrée / how-FriendFeed utilisations-mysql )
Les idées de personnes qui ont fait un changement serait grandement apprécié!
Merci.
La solution
Cassandra et les autres bases de données distribuées disponibles aujourd'hui ne fournissent pas le genre de soutien de requête ad hoc que vous êtes habitué à partir sql. En effet, vous ne pouvez pas distribuer les requêtes avec les jointures performantly, donc l'accent est mis sur la place dénormalisation.
Cependant, Cassandra 0.6 (bêta officiellement demain, mais vous pouvez construire à partir de la branche 0.6 vous-même si vous êtes impatient) prend en charge la carte Hadoop / réduire pour l'analyse, ce qui semble en fait comme un bon moyen pour vous.
Cassandra fournit un excellent support pour l'ajout de nouveaux noeuds sans douleur, même à un groupe initial de celui-ci.
Cela dit, à quelques centaines écrit / minute, vous allez être bien sur MySQL pour une longue, très longtemps. Cassandra est beaucoup mieux d'être un magasin clé / valeur (encore mieux, clé / columnfamily) mais MySQL est beaucoup mieux d'être une base de données relationnelle. :)
Il n'y a pas de soutien de django pour Cassandra (ou toute autre base de données NoSQL) encore. Ils parlent de faire quelque chose pour la prochaine version après 1.2, mais en fonction de parler à django devs à PyCon, personne ne sait vraiment ce que cela va ressembler encore.
Autres conseils
Si vous êtes un développeur de base de données relationnelle (comme je suis), je vous suggère / signaler:
- Obtenir une expérience de travail avec Cassandra avant de vous engager à son utilisation sur un système de production ... surtout si ce système de production dispose d'un délai difficile pour l'achèvement. Peut-être utiliser comme le back-end pour quelque chose peu importantes.
- Il est la preuve plus difficile que je ne l'avais anticipé de faire des choses simples que je prends pour acquis sur la manipulation de données en utilisant les moteurs SQL. En particulier, les données d'indexation et de tri des ensembles de résultats est non trivial.
- La modélisation des données a révélé difficile aussi bien. En tant que développeur de base de données relationnelle vous venez à la table avec beaucoup de bagages ... vous devez être prêt à apprendre comment modéliser des données très différemment.
dit ces choses, je recommande fortement la construction quelque chose Cassandra. Si vous êtes comme moi, cela lui permet de remettre en question votre compréhension du stockage de données et vous faire repenser une perspective base de données relationnelle-fits-all-situations que je ne savais même pas que je tenais.
Quelques bonnes ressources que j'ai trouvé comprennent:
Le Django-cassandra est un mode bêta précoce. Aussi Django n'a pas fait pour les bases de données non-SQL. La clé de Django ORM est basée sur SQL (Django recommande d'utiliser PostgreSQL). Si vous devez utiliser SEULEMENT sans sql (vous pouvez mélanger sql et non-sql dans la même application), vous devez utiliser risque de non-sql ORM (significativement plus lent que ORM SQL traditionnelle ou l'utilisation directe de stockage non-SQL). Ou vous aurez besoin de réécrire complètement plein django ORM. Mais dans ce cas, je ne peux pas présumer, pourquoi vous avez besoin de Django. Peut-être que vous pouvez utiliser quelque chose d'autre, comme Tornado?
