Je suis au milieu de la construction d'une nouvelle application qui aura des fonctionnalités très similaires à Facebook et, bien que évidemment, cela n'aura jamais besoin de faire face à des goûts de 400 000 000 millions d'utilisateurs, il sera toujours utilisé par une base d'utilisateurs substantielle et la plupart de ils l'exigeront très très vite.
J'ai une vaste expérience avec MySQL, mais une application sociale offre des complexités que MySQL n'est pas bien adaptée également. Je connais Facebook, Twitter, etc., je suis dirigé vers Cassandra pour beaucoup de leurs données, mais je ne suis pas sûr de la distance avec ça.
Par exemple, conservez-vous des choses telles que des données utilisateur - Nom d'utilisateur, mots de passe, adresses, etc. à Cassandra? Voulez-vous stocker des courriels, des commentaires, des mises à jour de statut, etc. à Cassandra? J'ai également lu beaucoup que quelque chose comme Neo4j est beaucoup mieux pour représenter les relations d'amis utilisées par les applications sociales car c'est une base de données graphique. Je ne fais que commencer simplement sur la route NOSQL afin que toute directive soit grandement appréciée.
Quelqu'un pourrait-il être capable de me conseiller sur cela? J'espère que je ne suis pas trop général!
4 Réponses :
Facebook n'a pas déplacer à Cassandra, ils l'ont créée. :) À ma connaissance, NOSQL DBMSES ne nécessite pas Je dirais que si Cassandra est assez bon pour Facebook, il est susceptible d'être assez bon pour votre projet. Il pourrait ne pas faire mal d'essayer de résumer la logique de persistance afin que vous ayez la possibilité de passer à autre chose, si cela vient absolument à cela.
Clause de non-responsabilité: Je n'ai pas (encore?) Avait des mains sur l'expérience des bases de données NOSQL: ce que je sais vient de lire à ce sujet.
Il semble que vous mélangez des concepts ici: NOSQL est un terme très abstrait et contient à la fois des bases de données acides qui ont fondamentalement les mêmes garanties que les SGBD typiques ont (par exemple DB4O) ainsi que des bases de données qui échouent, mais n'offrent pas le même ensemble. des garanties (par exemple, Cassandra) en matière de cohérence des données. Ces propriétés devraient être le guide des décisions. Je pense que ce type de logique est impossible, je crois: il y a une différence significative dans les données dont vous pouvez faire confiance, et des données que vous ne pouvez pas faire confiance. Les transactions pourraient ne pas avoir de sens, etc.
Abstraction Quel genre de logique? Transactions acides? La DB prend en charge ou ne les soutient pas: ce dont je parlais est fondamentalement prévu par exemple. Une mince couche DAO au-dessus de la base de données de manière à ce que la partie de l'application au-dessus de la couche DAO puisse rester plus ou moins intacte si la mise en œuvre DAO change (en raison d'un passage à une DB différente). En ce qui concerne le choix de la base de données de la base de données, Christopher a décrit le projet comme ayant des "caractéristiques très similaires à Facebook", il serait donc assez particulier s'il serait possible qu'il serait préférable que Christopher utilise une base de données différente de celle des utilisations sur Facebook.
Facebook n'utilise pas une base de données. Ils utilisent (au moins) Oracle, Cassandra et Hadoop en parallèle. Cassandra a été développé pour rechercher votre boîte de réception sur Facebook, pas pour stocker les détails de paiement. Vous ne pouvez pas mettre la même abstraction sur différentes choses, c'est-à-dire d'utiliser un DAO pour un magasin de données cohérent et celui qui n'est finalement éventuellement cohérent.
Vous avez raison, ils utilisent Oracle. Je mettrai à jour ma réponse en conséquence, merci pour la correction.
Ils utilisent MySQL comme magasin de données primaire. Ils écrivent ici ici: facebook.com/mysqlatfacebook
Je suggérerais de faire des tests avec MySQL et avec Cassandra. Lorsque nous devions faire le choix entre PostgreSQL et MongoDB dans l'un de mes emplois, nous avons comparé le temps de requête sur des millions d'enregistrements dans les deux et découverts qu'avec environ 10 m records Postgres nous fournirait des temps de réponse adéquats.
Nous savions que nous ne serions pas à ce nombre d'enregistrements pendant au moins deux ans et que nous avions de l'expérience avec les postgres (tandis que MongoDB n'était pas très mature à l'époque), nous sommes donc allés avec Postgres. < / p>
Mon point est que vous pouvez probablement regarder les points de repère MySQL, faire des tests de performance vous-même, estimer la taille de votre ensemble de données et sa croissance et faire une décision éclairée de cette façon.
En ce qui concerne le mélange de bases de données relationnelles et non relationnelles, c'est quelque chose que nous considérions également, mais a décidé que ce serait trop de problème, car cela signifierait le maintien de deux types de logiciels et écrire un peu de code de colle. pour obtenir les données des deux. Je pense que Cassandra serait parfaitement capable de stocker toutes vos données.
Par exemple, conservez-vous des choses telles que des données utilisateur - Nom d'utilisateur, mots de passe, adresses, etc. à Cassandra?
Non, puisqu'il ne garantit pas la cohérence. Cassandra est éventuellement cohérent . Il ne devrait sûrement pas y avoir de concurrence sur les données de certains comptes d'utilisateur, mais je ne voudrais pas y parier. Vous n'avez peut-être pas besoin de cohérence sur votre recherche Fulltext, votre boîte de réception de message, etc. Mais vous voulez une cohérence dans tout ce qui est liée à la sécurité.
J'ai aussi lu beaucoup que quelque chose comme Neo4J est beaucoup mieux mieux pour représenter les relations d'amis utilisées par les applications sociales car il s'agit d'une base de données graphique.
Je suis un grand fan du bon outil pour le bon travail. Je n'ai pas utilisé Neo4j mais j'utilise db4o (qui est une base de données d'objets) et le trouve très utile. Il facilite le développement d'utiliser un outil qui soutient de manière native vos besoins. Puisque vous avez besoin de graphiques et que vous travaillez avec des graphiques dans SQL, c'est une douleur, je recommanderais de lui donner un look et d'évaluer s'il convient de vos besoins spécifiques.
Mélange de bases de données sonne comme une bonne idée pour moi tant que le choix est naturel (c'est-à-dire que la base de données correspondante est utile pour les travaux spécifiques, une base de données graphiques pour les graphiques, une table pour les tables, des bases de données acides pour tout ce qui nécessite une sécurité des transactions. , etc...).
Je ne vois pas pourquoi vous ne stockeriez pas toutes les données à Cassandra à part le fait qu'il est plus facile de les interroger dans un SGBDM. Cassandra garantit la consistance si vous le souhaitez (quorum lit / écrit), voir spyced.blogspot.com/2010/04/cassandra-fact-vs-fiction.html . Si vous vous demandez de fiabilité, voir thread.gmane.org/gmane.fr .db.cassandra.user / 3454
Merci pour les liens intéressants. Je ne suis pas tout à fait sûr de cela, mais d'après ce que j'ai compris, vous pouvez garantir la cohérence entre les nœuds, mais "transactions", c'est-à-dire au niveau du lot n'est pas atomique, n'est-ce pas? Si cela pose vraiment un problème est une deuxième question. Je pense que ce type de données est exactement ce que les SGBDM ont été faites pour, mais vous avez un point là-bas lorsqu'il s'agit de la tolérance de disponibilité / partition, il pourrait donc être préférable d'utiliser Cassandra pour des données utilisateur dans certains scénarios.
Cassandra fournit une belle solution distribuée et probablement mieux pour une plate-forme de Facebook comme MySQL (si elle devra échouer). Mais Cassandra ne convient pas aux relations de données où vous aurez un défi de relation à plusieurs à plusieurs. Une base de données graphique liée à Cassandra fournirait à la fois les besoins en volume en vrac, ainsi qu'une capacité de requête relationnelle très rapide. Nous travaillons sur quelque chose qui combine les deux technologies et toujours intéressé par les types d'exigences que votre plate-forme présenterait. Si vous avez des questions sur la manière de gérer certains problèmes liés aux données, j'adorerais les entendre, peut-être que nous pouvons vous aider à comprendre.
Je suis fortement en désaccord avec votre affirmation selon laquelle Cassandra n'est pas bonne pour représenter de nombreuses relations. Pour résoudre un problème comme celui-ci à Cassandra, il vous suffit de stocker des index pour chaque relation des deux directions. Par exemple, si vous aviez besoin de stocker des relations entre les utilisateurs tels que l'utilisateur A est suivant l'utilisateur B, vous pouvez créer des familles de colonnes comme suit et suivantes. La clé de chaque CF serait un identifiant utilisateur et chaque ligne n'aurait qu'une colonne par identifiant utilisateur dans cet ensemble. Vous pouvez toujours stocker ces relations, il vous suffit de stocker les points de vue à l'avance.
Neo4J ne prend pas en charge le frisson et n'a pas de très faible performance dans d'énormes données. Nous avons testé