Quand NE PAS utiliser Cassandra?
On a beaucoup parlé de Cassandra récemment.
Twitter, Digg, Facebook, etc. l'utilisent tous.
Quand est-il judicieux de:
- utiliser Cassandra,
- n'utilisez pas Cassandra, et
- utilisez un RDMS au lieu de Cassandra.
Rien ne vaut une solution miracle, tout est conçu pour résoudre des problèmes spécifiques et a ses propres avantages et inconvénients. C'est à vous de décider quel problème vous avez et quelle est la solution la mieux adaptée à ce problème.
Je vais essayer de répondre à vos questions une par une dans le même ordre que vous leur avez posé. Puisque Cassandra est basé sur la famille de bases de données NoSQL, il est important de comprendre pourquoi vous utilisez une base de données NoSQL avant de répondre à vos questions.
Pourquoi utiliser NoSQL
Dans le cas des SGBDR, le choix est assez facile car toutes les bases de données telles que MySQL, Oracle, MS SQL, PostgreSQL offrent dans cette catégorie presque le même type de solutions orientées vers les propriétés ACID. La décision devient difficile en ce qui concerne NoSQL, car chaque base de données NoSQL offre différentes solutions et vous devez savoir laquelle est la mieux adaptée à vos besoins en matière d'applications et de système. Par exemple, MongoDB est adapté aux cas d’utilisation où votre système exige un magasin de documents sans schéma. HBase peut convenir aux moteurs de recherche, à l'analyse des données de journalisation ou à tout autre endroit où la numérisation de vastes tables sans jointures en deux dimensions est une nécessité. Redis est conçu pour permettre la recherche en mémoire de diverses structures de données telles que des arbres, des files d'attente, des listes chaînées, etc., et peut être un bon moyen de créer des classements en temps réel, des systèmes de type pub-sub. De même, il existe d'autres bases de données dans cette catégorie (y compris Cassandra) qui conviennent à différentes déclarations de problèmes. Passons maintenant aux questions initiales et répondons-y une à une.
Quand utiliser Cassandra
En tant que membre de la famille NoSQL, Cassandra) offre une solution aux problèmes pour lesquels l’un de vos besoins est d’avoir un système d’écriture très lourd et pour lequel vous souhaitez avoir un système de reporting très réactif. Considérez le cas d'utilisation de l'analyse Web où les données de journal sont stockées pour chaque demande et vous souhaitez créer une plate-forme analytique pour compter les hits par heure, par navigateur, par IP, etc. en temps réel. à this blog pour en savoir plus sur les cas d’utilisation où Cassandra s’intègre dans.
Quand utiliser un RDMS au lieu de Cassandra
Cassandra est basée sur une base de données NoSQL et ne fournit pas de propriétés de données relationnelles et ACID. Si vous avez une forte exigence pour les propriétés ACID (par exemple, Données financières), Cassandra ne conviendrait pas dans ce cas. Évidemment, vous pouvez créer une solution de contournement pour cela, mais vous finirez par écrire beaucoup de code d’application pour simuler les propriétés d’ACID vous fera perdre beaucoup de temps à la commercialisation. Gérer ce type de système avec Cassandra serait complexe et fastidieux pour vous.
Quand ne pas utiliser Cassandra
Je ne pense pas qu'il faille y répondre, si l'explication ci-dessus est logique.
Lorsque vous évaluez des systèmes de données distribuées, vous devez prendre en compte le théorème CAP. Vous pouvez choisir deux options parmi les suivantes: cohérence, disponibilité et tolérance de partition.
Cassandra est un système disponible, tolérant aux partitions, qui prend en charge la cohérence éventuelle. Pour plus d'informations, consultez ce billet de blog que j'ai écrit: Guide visuel des systèmes NoSQL .
Cassandra est la réponse à un problème particulier: que faites-vous lorsque vous avez tellement de données que celles-ci ne tiennent pas sur un serveur? Comment stockez-vous toutes vos données sur de nombreux serveurs sans casser votre compte bancaire et ne pas rendre vos développeurs fous? Facebook récupère 4 téraoctets de nouvelles données compressées CHAQUE JOUR. Et ce nombre augmentera probablement plus de deux fois en un an.
Si vous ne disposez pas de cette quantité de données ou si vous avez des millions à payer pour l'installation du cluster Enterprise Oracle/DB2 et les spécialistes requis pour la configurer et la maintenir, la base de données SQL vous convient.
Cependant, Facebook n'utilise plus cassandra) et utilise maintenant presque exclusivement MySQL pour déplacer le partitionnement vers le haut de la pile d'applications, ce qui permet des performances plus rapides et un meilleur contrôle.
L'idée générale de NoSQL est que vous devez utiliser le magasin de données le mieux adapté à votre application. Si vous avez une table de données financières, utilisez SQL. Si vous avez des objets nécessitant des requêtes complexes/lentes pour être mappés à un schéma relationnel, utilisez un magasin d'objets ou un magasin de clés/valeurs.
Bien sûr, à peu près tous les problèmes du monde que vous rencontrez se situent quelque part entre ces deux extrêmes et aucune solution ne sera parfaite. Vous devez tenir compte des capacités de chaque magasin et des conséquences de l’utilisation de l’un sur l’autre, qui seront très spécifiques au problème que vous essayez de résoudre.
En plus des réponses données ci-dessus sur le moment d'utilisation et le non-usage de Cassandra, si vous décidez d'utiliser Cassandra, vous pouvez envisager de ne pas utiliser Cassandra lui-même , mais l’un de ses nombreux cousins.
Certaines réponses ci-dessus indiquaient déjà divers systèmes "NoSQL" partageant de nombreuses propriétés avec Cassandra, avec quelques différences mineures ou importantes, et pouvant être meilleurs que Cassandra elle-même pour vos besoins spécifiques.
De plus, récemment (plusieurs années après que cette question a été posée à l'origine), un clone Cassandra appelé Scylla (voir https://en.wikipedia.org/fr/scylla_ (base de données))) ) Scylla est une ré-implémentation open source de Cassandra en C++, qui prétend avoir un débit nettement supérieur et des latences plus faibles que l'original Java Cassandra, tout en étant principalement compatible avec ce dernier (fonctionnalités, API et formats de fichier), donc si vous envisagez déjà Cassandra, vous pouvez également envisager Scylla.
Parler avec quelqu'un en train de déployer Cassandra ne lui permet pas de bien gérer le multi-plusieurs. Ils font un travail de piratage pour faire leurs tests initiaux. J'ai parlé à un consultant Cassandra) et il a dit qu'il ne le recommanderait pas si vous aviez réglé ce problème.
Vous devriez vous poser les questions suivantes:
- (Volume, Velocity) Voulez-vous écrire et lire des TONNES d’informations, tellement d’informations qu’aucun ordinateur ne peut gérer les écritures?.
- (Global) Aurez-vous besoin de cette capacité d’écriture et de lecture dans le monde entier pour que les écrits d’une partie du monde soient accessibles dans une autre partie du monde?
- (Fiabilité) Avez-vous besoin que cette base de données soit opérationnelle tout le temps et ne tombe jamais en panne, quel que soit le cloud, le pays, que ce soit VM, Container, ou métal nu?
- ((Scalable-capacité)) Avez-vous besoin de cette base de données pour pouvoir continuer à croître facilement et à évoluer de manière linéaire
- (Consistency) Avez-vous besoin d'une cohérence TUNABLE dans laquelle certaines écritures peuvent se produire de manière asynchrone alors que d'autres doivent être certifiées?
- (Compétence) Êtes-vous prêt à faire ce qu'il faut pour apprendre cette technologie et la modélisation des données qui accompagne la création d'une base de données distribuée dans le monde entier qui peut être rapide pour tout le monde, partout?
Si pour ces questions vous pensiez "peut-être" ou "non", vous devriez utiliser autre chose. Si vous aviez la réponse à toutes ces questions, alors vous devriez utiliser Cassandra.
Utilisez le SGBDR lorsque vous pouvez tout faire sur une boîte. C'est probablement plus facile que la plupart et tout le monde peut travailler avec.
@Paco Désolé de faire éclater votre bulle, mais surtout en ce qui concerne les données financières, la cohérence des transactions est cruciale. Comme cela a été souligné dans des bases de données telles que Cassandra, un script défaillant peut laisser des effets secondaires, pouvant inclure une table mise à jour et une autre non. Un exemple: 100 £ correspond au transfert du compte de l'utilisateur 1 au compte de l'utilisateur 2. Une transaction est enregistrée pour chaque compte, montrant qu'il est supprimé de l'un et ajouté à l'autre. Bien sûr, cela dépend de votre conception. Dans un autre scénario, un paiement est effectué à la banque. Les fonds doivent être retirés d'un compte et ajoutés à un autre. Un manque d'uniformité laisserait la possibilité que de l'argent disparaisse du système ou soit compté deux fois. Dans les deux cas, la banque se trouve en difficulté.
Dans de nombreux cas, la cohérence transactionnelle est essentielle pour les entreprises. Soit elle est gérée de manière sûre et efficace par l’application, soit la base de données doit la gérer elle-même, cette dernière étant l’option "sûre".
L’absence de soutien à la participation via cassandra en limite l’utilisation, à moins que d’autres applications appropriées ne soient utilisées avec elle. À ce propos, le manque de fonctions de déclencheur, de clés étrangères, etc. Si vous êtes un moteur de recherche, par exemple, et que vous avez une vaste base de clientèle, Cassandra pourrait bien s’adapter parfaitement. Pour OLTP, et certains cas de rapport, en revanche, ou une charge moins lourde volumes, il peut s’agir d’une inadéquation totale par rapport aux exigences.
Requête simple lourde vs requête légère gazillion La charge est un autre point à prendre en compte, en plus des autres réponses fournies ici. Il est intrinsèquement plus difficile d'optimiser automatiquement une requête unique dans une base de données de type NoSql. J'ai utilisé MongoDB et rencontré des problèmes de performances lors de la tentative de calcul d'une requête complexe. Je n'ai pas utilisé Cassandra mais j'attends qu'il ait le même problème.
D'autre part, si votre charge est supposée être celle d'un très grand nombre de petites requêtes et que vous souhaitez pouvoir facilement évoluer, vous pouvez tirer parti de la cohérence éventuelle offerte par la plupart des bases de données NoSql. Notez que la cohérence éventuelle n'est pas vraiment une caractéristique d'un modèle de données non relationnel, mais qu'elle est beaucoup plus facile à implémenter et à configurer dans un système basé sur NoSql.
Pour une requête unique et très lourde, tout moteur de SGBDR moderne peut effectuer un travail correct en parallélisant certaines parties de la requête et tirer parti du volume de ressources processeur et mémoire que vous lui envoyez (sur une seule machine). Les bases de données NoSql ne disposent pas d'assez d'informations sur la structure des données pour pouvoir émettre des hypothèses permettant une parallélisation réellement intelligente d'une requête volumineuse. Ils vous permettent d’évoluer facilement plusieurs serveurs (ou cœurs), mais une fois que la requête atteint un niveau de complexité, vous devez la diviser manuellement en parties que le moteur NoSql sait gérer de manière intelligente.
D'après mon expérience avec MongoDB, finalement, en raison de la complexité de la requête, Mongo ne pouvait pas faire grand chose pour l'optimiser et l'exécuter en partie sur plusieurs données. Mongo parallélise plusieurs requêtes mais n'est pas très bon pour optimiser une seule.
Lisons quelques cas réels:
http: //planetcassandra.org/Apache-cassandra-use-cases/
Dans cet article: http: //planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-Apache-cassandra
Ils ont expliqué pourquoi ils n'ont pas choisi MySql parce que la synchronisation de la base de données est trop lente.
(Également en raison de la validation en 2 phrases, FK, PK)
Cassandra est basée sur du papier Amazon Dynamo
Fonctionnalités:
La stabilité
La haute disponibilité
La sauvegarde fonctionne bien
Lire et écrire est meilleur que HBase, (clone BigTable en Java).
wiki http: //en.wikipedia.org/wiki/Apache_Cassandra
Leur conclusion est:
We looked at HBase, Dynamo, Mongo and Cassandra.
Cassandra was simply the best storage solution for the majority of our data.
À partir de 2018,
Je recommanderais d'utiliser ScyllaDB pour remplacer la cassandra classique, si vous avez besoin de soutien pour le dos.
Le plugin Postgres kv est aussi rapide que cassandra. Comment jamais n'aura l'évolutivité multi-instance.
une autre situation qui facilite le choix est lorsque vous souhaitez utiliser une fonction d'agrégation telle que somme, min, max, etc. et des requêtes complexes (comme dans le système financier mentionné ci-dessus), une base de données relationnelle est probablement plus pratique qu'une base de données nosql pas possible sur une base de données nosql à moins que vous n'utilisiez beaucoup d'index inversés. Lorsque vous utilisez nosql, vous devez exécuter les fonctions d'agrégation dans le code ou les stocker séparément dans sa propre famille de colonnes, mais cela rend le tout assez complexe et réduit les performances que vous avez obtenues en utilisant nosql.
Je vais me concentrer ici sur certains aspects importants qui peuvent vous aider à décider si vous avez vraiment besoin de Cassandra. La liste n’est pas exhaustive, ce ne sont que quelques-uns des points qui me préoccupent le plus.
Ne considérez pas Cassandra comme le premier choix lorsque vous avez une exigence stricte en matière de relation (dans votre ensemble de données).
Cassandra est par défaut le système AP (de CAP). Mais, il prend en charge la cohérence ajustable, ce qui signifie qu'il peut également être configuré pour prendre en charge en tant que CP. Donc, ne l'ignorez pas simplement parce que vous lisez quelque part qu'il s'agit de l'AP et que vous recherchez des systèmes CP. Cassandra est plus précisément appelé "accordable, ce qui signifie il vous permet de choisir facilement le niveau de cohérence requis, en adéquation avec le niveau de disponibilité.
Ne pas utiliser Cassandra si votre balance n’est pas beaucoup ou si vous pouvez traiter avec une base de données non distribuée.
Pensez plus fort si votre équipe pense que tous vos problèmes seront résolus si vous utilisez des bases de données distribuées comme Cassandra. Commencer avec ces bases de données est très simple car il est livré avec de nombreux paramètres par défaut, mais son optimisation et sa maîtrise en vue de résoudre un problème spécifique nécessiteraient un effort considérable (sinon considérable) d’ingénierie.
Cassandra est orientée colonne mais chaque ligne a également une clé unique. Il peut donc être utile de penser à cela comme à un magasin indexé, orienté ligne. Vous pouvez même l'utiliser comme magasin de documents.
Cassandra ne vous oblige pas à définir les champs à l'avance. Donc, si vous êtes en mode de démarrage ou que vos fonctionnalités évoluent (comme dans l'agile) - Cassandra l'adopte. Alors, mieux, réfléchissez d'abord aux requêtes, puis aux données réponds-y.
Cassandra est optimisée pour un débit très élevé en écriture. Si votre cas d'utilisation est lourd en lecture (comme le cache), alors Cassandra pourrait ne pas être un choix idéal.
Cassandra est un bon choix si:
Vous n'avez pas besoin des propriétés ACID de votre base de données.
Il y aurait un nombre énorme et énorme d'écritures sur la base de données.
Il est nécessaire d'intégrer Big Data, Hadoop, Hive et Spark.
Il y a un besoin d'analyse de données en temps réel et de générations de rapports.
Un mécanisme de tolérance aux pannes impressionnant est requis.
Il y a une exigence de système homogène.
Il y a une exigence de beaucoup de personnalisation pour le réglage.
Si vous avez besoin d’une base de données entièrement cohérente avec la sémantique SQL, Cassandra n’est PAS la solution pour vous. Cassandra prend en charge les recherches de valeur/clé. Il ne prend pas en charge les requêtes SQL. Les données dans Cassandra est "éventuellement cohérent". Les recherches simultanées de données peuvent être incohérentes, mais les recherches finissent par être cohérentes.
Si vous avez besoin d'une sémantique stricte et avez besoin d'une prise en charge pour les requêtes SQL, choisissez une autre solution telle que MySQL, PostGres ou combinez l'utilisation de Cassandra avec Solr.
- Il ne prend pas en charge la gestion complète des transactions entre les tables.
- Index secondaire non pris en charge.
- Il faut compter sur Elastic search/Solr for Secondary index et le composant de synchronisation personnalisé doit être écrit.
- Système non compatible ACID.
- Le support de requête est limité.
Apache cassandra est une base de données distribuée permettant de gérer de grandes quantités de données structurées sur de nombreux serveurs de base, tout en fournissant un service hautement disponible et sans point de défaillance unique.
L'architecture est purement basée sur le théorème de cap, qui est la disponibilité, la tolérance de partition et, de manière intéressante, toujours cohérente.
Dont Use, si vous ne stockez pas de volumes de données sur des racks de clusters, Dont use si vous ne stockez pas de données chronologiques, Dont Use si vous ne désinfectez pas vos serveurs, Dont use si vous avez besoin d'une grande cohérence.
Mongodb a des fonctions d'agrégats très puissantes et un cadre d'agrégats expressif. Il offre de nombreuses fonctionnalités que les développeurs ont l'habitude d'utiliser depuis le monde des bases de données relationnelles. Sa structure de données/stockage de documents permet des modèles de données plus complexes que Cassandra, par exemple.
Tout cela vient avec des compromis bien sûr. Ainsi, lorsque vous sélectionnez votre base de données (NoSQL, NewSQL ou SGBDR), examinez le problème que vous tentez de résoudre et vos besoins en évolutivité. Aucune base de données ne fait tout.
Selon DataStax, Cassandra n’est pas le meilleur des cas d’utilisation lorsque
1- Périphériques matériels haut de gamme. 2- Compatible ACID sans annulation (transaction bancaire)