Potentiel futur de passer de MySQL à Cassandra (NoSQL)

Question

Je prévois éventuellement de passer du système de base de données de mon site MySQL à NoSQL (dans ce cas, Cassandra). D'après ce que j'ai compris jusqu'à présent à propos de Cassandra, il n'y a pas de jointure, mais plutôt des enregistrements plus volumineux qui fonctionnent plus efficacement. Je ne suis en aucun cas un expert en NoSQL atm, je comprends vraiment très peu à ce sujet et suis très confus sur la façon dont beaucoup de cela fonctionne ...

Un de mes objectifs pour mon projet web est de passer en Python et Cassandra pour une solution plus avancée et plus rapide au fur et à mesure que mon site Web commence à croître et que je veux être en mesure de l'adapter facilement à d'autres serveurs.

Actuellement, je suis en train de concevoir une nouvelle fonctionnalité pour mon site Web, la possibilité de prendre des fichiers et de créer des dossiers à partir de ceux-ci. Jusqu'ici c'est ce que j'utilisais à l'origine: How to join/subquery a second table (Une question que je viens de poser)

Ensuite, les gens proposaient de normaliser les données et de faire un système de 3 tables dont une pour les dossiers, une pour les dossiers/fichiers, et un pour les fichiers. @ egrunin a répondu à ma question et m'a même donné l'info pour le NoSQL, mais je voulais vraiment le vérifier avec une seconde source juste pour m'assurer que c'est la bonne approche.

Existe-t-il des outils de conversion pour SQL vers NoSQL? Donc, mon but ultime est de concevoir ce dossier/système de fichiers dans la base de données (avec d'autres fonctionnalités que j'ajoute) de sorte que lorsque je passerai de SQL à NoSQL je serai prêt et la conversion de toutes mes données sera beaucoup plus facile. Tous les tutoriels, guides et informations sur la conversion de SQL vers NoSQL, Cassandra, ou comment fonctionne NoSQL sont très appréciés, jusqu'à présent, la documentation de Cassandra m'a laissé très confus.

Answer 1

À Couchbase nous avons récemment fait une série de webinaires sur la transition de SGBDR à NoSQL. C'est évidemment à travers l'objectif des documents JSON, mais beaucoup de leçons s'appliqueront à n'importe quelle base de données distribuée.

http://www.couchbase.com/webinars

Answer 2

MasterGberry:

Un de mes objectifs pour mon projet web est de passer à Python et Cassandra pour une solution plus avancée et plus rapide que mon site commence à se développer et je veux être en mesure d'escalader facilement avec des serveurs supplémentaires.

Ceci est quelque chose que vous devez quantifier clairement avant de passer à Cassandra. MySQL peut faire amazing things et Cassandra peut aussi, mais passer à Cassandra ne peut généralement pas être conduit simplement en voulant faire les choses plus rapidement, car ils pourraient ne pas être plus rapide - du moins pas dans les domaines où vous êtes utilisé pour MySQL super (agrégats numériques au niveau des colonnes sur des données tabulaires bien définies). Je ne décourage nullement la transition, mais je préviens des attentes.

Cela pourrait être une bonne lecture: http://itsecrets.wordpress.com/2012/01/12/jumping-from-mysql-to-cassandra-a-success-story/

Answer 3

En fait, vous pouvez utiliser un outil comme playOrm pour soutenir rejoint, mais sur des partitions seulement NOT tables entières.Donc, si vous partitionnez par mois ou par compte, vous pouvez récupérer la partition du compte 4536 et interroger celle qui la rejoint avec quelque chose d'autre (soit une autre table plus petite ou une autre partition d'une autre table). Ceci est très utile si vous avez un système avec beaucoup de clients et que chaque client est vraiment indépendant d'un autre client car vous pouvez contenir toutes les informations client dans les partitions de ce client de toutes les tables.

plus tard, Dean

Answer 4

Cassandra est pas vraiment censé être le stockage principal d'une application. L'un de ses principaux objectifs est de stocker des données séquentielles et de tout récupérer avec une recherche de clé. Un exemple est la journalisation. Fait intéressant, les clés de ligne ne sont pas triées, mais les noms de colonnes sont. Donc, la journalisation aurait une clé pour chaque minute, puis créer une nouvelle colonne pour chaque entrée de journal avec un horodatage séquentiel comme nom de la colonne. Ce n'est qu'un exemple bien sûr, l'histoire du chat en est une autre.