Cassandra à la place de MySQL pour l'application de réseau social

Question

Je suis au milieu de la construction d'une nouvelle application qui ont des caractéristiques très semblables à Facebook et bien évidemment, il a l'habitude de toujours faire face aux goûts de 400.000.000 millions d'utilisateurs, il sera toujours utilisé par une base d'utilisateurs importante et la plupart des les exigeront courir très très vite.

Je possède une grande expérience avec MySQL, mais une application sociale offre complexités MySQL ne convient pas trop. Je sais que Facebook, Twitter, etc ont évolué vers Cassandra pour beaucoup de leurs données, mais je ne suis pas sûr jusqu'où aller avec elle.

Par exemple vous voulez stocker des choses telles que les données utilisateur - nom d'utilisateur, mots de passe, adresses, etc à Cassandra? Souhaitez-vous stocker les e-mails, des commentaires, l'état des mises à jour, etc à Cassandra? J'ai aussi lu beaucoup que quelque chose comme Neo4j est beaucoup mieux pour représenter les relations ami utilisé par les applications sociales est une base de données de graphique. Je ne fait que commencer dans la voie NoSQL de sorte que toute orientation est grandement appréciée.

Quelqu'un pourrait me conseiller sur ce point? J'espère que je ne suis pas trop général!

Answer 1

  

Par exemple vous voulez stocker des choses telles que les données utilisateur - nom d'utilisateur, mots de passe, adresses, etc à Cassandra?

Non, car il ne garantit pas la cohérence. Cassandra est éventuellement cohérente . Certes, il ne devrait pas être sur les données concurrency d'un certain compte utilisateur, mais je ne voudrais pas parier là-dessus. Vous pourriez ne pas avoir besoin de cohérence sur votre recherche en texte intégral, votre boîte de réception de messages, etc., mais vous voulez la cohérence dans tout ce qui est lié à la sécurité.

  

J'ai aussi lu beaucoup que quelque chose comme Neo4j est beaucoup mieux pour représenter les relations ami utilisé par les applications sociales est une base de données graphique.

Je suis un grand fan de l'outil pour le bon travail. Je ne l'ai pas utilisé Neo4j mais je l'ai utilisé db4o (qui est une base de données objet) et le trouve très utile. Il rend le développement plus facile d'utiliser un outil qui prend en charge nativement vos besoins. Puisque vous avez besoin de graphiques et de travailler avec des graphiques dans SQL est une douleur, je vous recommande de lui donner un coup d'oeil, et évaluer si elle répond à vos besoins spécifiques.

bases de données de mélange sonne comme une bonne idée de moi aussi longtemps que le choix est naturel (la base de données correspondante est utile avec les emplois spécifiques, une base de données de graphique pour les graphiques, une table pour les tables, les bases de données ACID pour tout ce qui a besoin de sécurité des transactions , etc...).

Answer 2

Je vous conseille de faire quelques tests avec MySQL et Cassandra. Lorsque nous avons dû faire un choix entre PostgreSQL et MongoDB dans un de mes emplois, nous avons comparé le temps de recherche sur des millions d'enregistrements dans les deux et découvert que, avec environ 10 millions de dossiers Postgres nous fournirait des temps de réponse adéquats.

Nous savions que nous ne serions pas arriver à ce nombre d'enregistrements pendant au moins deux ans, et nous avons eu l'expérience avec Postgres (alors que MongoDB était pas très mature à l'époque), donc nous sommes allés avec Postgres.

Mon point est que vous pouvez probablement regarder de tests de MySQL, faites un peu de performance Vous-même, estimer la taille de votre ensemble de données et comment il va grandir et prendre une décision éclairée de cette façon.

En ce qui concerne le mélange des bases de données relationnelles et non relationnelles, il est quelque chose que nous considéré comme bien, mais a décidé qu'il serait trop compliqué, car cela signifierait le maintien de deux types de logiciels, et d'écrire un peu de code colle pour obtenir les données des deux. Je pense que Cassandra serait parfaitement capable de stocker toutes vos données.

Answer 3

Facebook n'a pas move à Cassandra, ils l'ont créé. :) A ma connaissance, DBMSes NoSQL ne nécessitent pas ou même mention (grâce à mnemosyn pour la correction, Facebook utilise Oracle et Cassandra) placés côte à côte avec une base de données relationnelle. Cette est un exemple opposé (mémorisation d'informations d'utilisateur dans un nosql DB).

Je dirais que si Cassandra est assez bon pour Facebook, il est susceptible d'être assez bon pour votre projet. Il pourrait ne pas mal d'essayer de faire abstraction de la logique de la persistance de sorte que vous avez la possibilité de passer à autre chose, si elle est tout à fait à cela.

Disclaimer: Je ne l'ai pas (encore?) Eu des mains sur l'expérience des bases de données NoSQL. Ce que je sais vient de lire à ce sujet

Answer 4

Cassandra fournit une belle solution distribuée, et probablement mieux pour un Facebook comme plate-forme que MySQL (si elle aura besoin à l'échelle). Mais Cassandra ne convient pas aux relations de données où vous aurez un grand nombre à plusieurs défis de la relation. Une base de données graphique lié à Cassandra fournirait à la fois les besoins de volume en vrac, en plus d'une capacité de recherche de relation très rapide. Nous travaillons sur quelque chose qui combine les deux technologies, et toujours intéressé par les types d'exigences de votre plate-forme présenterait. Si vous avez des questions sur la façon de traiter certaines données liées à des questions que j'aimerais les entendre, on peut peut-être aider à comprendre.