Passer de MySQL à Cassandra - Pour / Contre?
Pour un peu de contexte - cette question concerne un projet s'exécutant sur une seule petite instance EC2 et est sur le point de migrer vers une instance moyenne. Les principaux composants sont Django, MySQL et un grand nombre d'outils d'analyse personnalisés écrits en python et Java, qui font le gros du travail. La même machine exécute également Apache.
Le modèle de données ressemble à ce qui suit: une grande quantité de données en temps réel est diffusée à partir de divers capteurs en réseau, et idéalement, j'aimerais établir une approche à long sondage plutôt que le sondage actuel toutes les 15 minutes (une limitation de calcul des statistiques et écriture dans la base de données elle-même). Une fois les données entrées, je stocke la version brute dans MySQL, laisse les outils d'analyse se détacher de ces données et stocke les statistiques dans quelques autres tableaux. Tout cela est rendu en utilisant Django.
Fonctionnalités relationnelles dont j'aurais besoin -
- Trier par [SliceRange dans l'API de Cassandra semble satisfaire cela]
- Par groupe
- Beaucoup de relations entre plusieurs tables [Les SuperColonnes Cassandra semblent bien fonctionner pour une à plusieurs]
- Sphinx me donne un joli moteur de texte intégral, donc c'est aussi une nécessité. [Sur Cassandra, le projet Lucandra semble satisfaire ce besoin]
Mon problème majeur est que les lectures de données sont extrêmement lentes (et les écritures ne sont pas très chaudes non plus). Je ne veux pas y mettre beaucoup d'argent et de matériel pour le moment, et je préférerais quelque chose qui peut évoluer facilement avec le temps. La mise à l'échelle verticale de MySQL n'est pas anodine dans ce sens (ou bon marché).
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 moyenne, est-ce que je gagnerais des avantages en lecture/écriture en passant à quelque chose comme Cassandra? Cet article (pdf) semble définitivement le suggérer. Actuellement, je dirais que quelques centaines d'écritures par minute seraient la norme. Pour les lectures - puisque les données changent toutes les 5 minutes environ, l'invalidation du cache doit se produire assez rapidement. À un moment donné, il devrait également pouvoir gérer un grand nombre d'utilisateurs simultanés. Les performances de l'application sont actuellement tuées sur MySQL en faisant des jointures sur de grandes tables même si des index sont créés - quelque chose de l'ordre de 32k lignes prend plus d'une minute à rendre. (Cela peut également être un artefact d'E/S virtualisées EC2). La taille des tableaux est d'environ 4 à 5 millions de lignes, et il existe environ 5 tableaux de ce type.
Tout le monde parle d'utiliser Cassandra sur plusieurs nœuds, étant donné le théorème CAP et la cohérence éventuelle. Mais, pour un projet qui commence à peine à grandir, a-t-il un sens de déployer un seul nœud cassandra? Y a-t-il des mises en garde? Par exemple, peut-il remplacer MySQL en tant que backend pour Django? [Est-ce recommandé?]
Si je change, je suppose que je devrai réécrire des parties de l'application pour faire beaucoup plus d '"administrivia" car je devrais faire plusieurs recherches pour récupérer des lignes.
Serait-il logique d'utiliser simplement MySQL comme magasin de valeurs clés plutôt qu'un moteur relationnel, et aller avec cette? De cette façon, je pouvais utiliser un grand nombre d'API stables disponibles, ainsi qu'un moteur stable (et devenir relationnel au besoin). (Message de Brett Taylor de Friendfeed à ce sujet - http://bret.appspot.com/entry/how-friendfeed-uses-mysql )
Tout point de vue de personnes qui ont effectué un changement serait grandement apprécié!
Merci.
Cassandra et les autres bases de données distribuées disponibles aujourd'hui ne fournissent pas le type de support de requête ad hoc auquel vous êtes habitué à partir de SQL. En effet, vous ne pouvez pas distribuer les requêtes avec des jointures de manière performante, l'accent est donc mis sur la dénormalisation à la place.
Cependant, Cassandra 0.6 (beta officiellement sortie demain, mais vous pouvez construire vous-même à partir de la branche 0.6 si vous êtes impatient) prend en charge Hadoop map/réduire pour l'analyse, ce qui semble en fait être un bon choix pour vous.
Cassandra fournit un excellent support pour ajouter de nouveaux nœuds sans douleur, même à un groupe initial d'un.
Cela dit, à quelques centaines d'écritures/minute, vous allez très bien sur mysql pendant très longtemps. Cassandra est bien meilleur pour être un magasin de clés/valeurs (encore mieux, famille de clés/colonnes) mais MySQL est beaucoup mieux pour être une base de données relationnelle. :)
Il n'y a pas encore de support Django pour Cassandra (ou autre base de données nosql). Ils parlent de faire quelque chose pour la prochaine version après 1.2, mais basé sur des discussions) à Django devs sur pycon, personne ne sait vraiment à quoi cela ressemblera encore.
Si vous êtes un développeur de bases de données relationnelles (comme moi), je suggère/souligne:
- Obtenez une certaine 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 a une échéance stricte pour l'achèvement. Peut-être l'utiliser comme backend pour quelque chose sans importance en premier .
- Il s'avère plus difficile que je ne l'avais prévu de faire des choses simples que je tiens pour acquises concernant la manipulation de données à l'aide de moteurs SQL. En particulier, l'indexation des données et le tri des jeux de résultats ne sont pas anodins.
- La modélisation des données s'est également avérée difficile. En tant que développeur de bases de données relationnelles, vous venez avec beaucoup de bagages ... vous devez être prêt à apprendre à modéliser les données très différemment.
Ces choses étant dites, je recommande fortement de construire quelque chose dans Cassandra. Si vous êtes comme moi, cela mettra à l'épreuve votre compréhension du stockage de données et vous fera repenser un Outlook de base de données relationnelle qui convient à tous les situations que je ne savais même pas que je détenais.
Voici quelques bonnes ressources que j'ai trouvées:
Le Django-cassandra est un mode bêta précoce. Aussi Django n'a pas fait pour les bases de données sans SQL. La clé dans Django ORM est basée sur SQL (Django recommande d'utiliser PostgreSQL). Si vous avez besoin pour utiliser UNIQUEMENT no-sql (vous pouvez mélanger sql et no-sql dans la même application), vous devez risquer d'utiliser l'ORM sans sql (il est beaucoup plus lent que l'ORM SQL traditionnel ou l'utilisation directe du stockage No-SQL). besoin de réécrire complètement Django ORM. Mais dans ce cas, je ne peux pas présumer, pourquoi vous avez besoin de Django. Peut-être pouvez-vous utiliser autre chose, comme Tornado?