Quand NE PAS utiliser Cassandra?

Il y a eu beaucoup de discussions sur Cassandra ces derniers temps.

Twitter, Digg, Facebook, etc. l'utilisent tous.

Quand est-il sensé de:

• utiliser Cassandra,
• ne pas utiliser Cassandra, et
• utilisez un RDMS au lieu de Cassandra.

Il n'y a rien de mieux qu'une solution miracle, tout est conçu pour résoudre des problèmes spécifiques et a ses avantages et ses inconvénients. C'est à vous de décider quel énoncé de problème vous avez et quelle est la meilleure solution 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é. Étant donné que Cassandra est basée sur la famille de bases de données NoSQL, il est important de comprendre pourquoi utiliser une base de données NoSQL avant de répondre à vos questions.

Pourquoi utiliser NoSQL

Dans le cas du SGBDR, faire un choix est assez facile car toutes les bases de données comme MySQL, Oracle, MS SQL, PostgreSQL de cette catégorie proposent quasiment le même type de solutions orientées vers les propriétés ACID. En ce qui concerne NoSQL, la décision devient difficile car chaque base de données NoSQL propose des solutions différentes et vous devez comprendre laquelle est la mieux adaptée aux exigences de votre application / 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 être adapté aux moteurs de recherche, à l'analyse des données de journal ou à tout autre endroit où l'analyse d'énormes tables bidimensionnelles sans jointure est une exigence. Redis est conçu pour fournir une recherche en mémoire de variétés de structures de données comme les arbres, les files d'attente, les listes liées, etc. et peut être un bon choix pour créer des classements en temps réel, type de système pub-sub. De même, il existe d'autres bases de données dans cette catégorie (y compris Cassandra) qui sont adaptées à différents énoncés de problèmes. Passons maintenant aux questions d'origine et répondez-y une par une.

Quand utiliser Cassandra

Faisant partie de la famille NoSQL, Cassandra offre une solution pour les problèmes où l'une de vos exigences est d'avoir un système d'écriture très lourd et que vous voulez avoir un système de rapport assez réactif en plus de ces données stockées. 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 construire une plate-forme analytique autour d'elle pour compter les hits par heure, par navigateur, par IP, etc. en temps réel. Vous pouvez vous référer à ce billet de blog pour en savoir plus sur les cas d'utilisation où Cassandra s'intègre.

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 ACID et relationnelles. Si vous avez une forte exigence pour les propriétés ACID (par exemple les données financières), Cassandra ne conviendrait pas dans ce cas. De toute évidence, vous pouvez contourner ce problème, mais vous finirez par écrire beaucoup de code d'application pour simuler les propriétés ACID et vous perdrez à temps pour mal commercialiser. La gestion de ce type de système avec Cassandra serait également complexe et fastidieuse pour vous.

Quand ne pas utiliser Cassandra

Je ne pense pas qu'il soit nécessaire d'y répondre si l'explication ci-dessus est logique.

Lors de l'évaluation de systèmes de données distribués, vous devez tenir compte du théorème CAP - vous pouvez choisir deux des éléments suivants: cohérence, disponibilité et tolérance de partition.

Cassandra est un système disponible et tolérant aux partitions qui prend en charge la cohérence éventuelle. Pour plus d'informations, consultez cet article 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 qu'elles ne tiennent pas sur un seul 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 obtient 4 téraoctets de nouvelles données compressées TOUS LES JOURS. Et ce nombre augmentera très probablement plus de deux fois en un an.

Si vous n'avez pas autant de données ou si vous avez des millions à payer pour l'installation du cluster Enterprise Oracle / DB2 et les spécialistes nécessaires pour le configurer et le maintenir, alors vous êtes bien avec la base de données SQL.

Cependant, Facebook n'utilise plus cassandra et utilise désormais MySQL presque exclusivement en déplaçant le partitionnement dans la pile d'applications pour 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 disposez d'un tableau de données financières, utilisez SQL. Si vous avez des objets qui nécessiteraient des requêtes complexes / lentes pour mapper à un schéma relationnel, utilisez un objet ou un magasin de clés / valeurs.

Bien sûr, à peu près tout problème du monde réel que vous rencontrez se situe quelque part entre ces deux extrêmes et aucune des solutions ne sera parfaite. Vous devez tenir compte des capacités de chaque magasin et des conséquences de l'utilisation de l'une sur l'autre, qui seront très spécifiques au problème que vous essayez de résoudre.

Outre les réponses données ci-dessus sur le moment d'utiliser et de ne pas utiliser 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" qui partagent de nombreuses propriétés avec Cassandra, avec quelques petites ou grandes différences, et peuvent être meilleurs que Cassandra lui-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 de Cassandra appelé Scylla (voir https://en.wikipedia.org/wiki/Scylla_(database) ) a été publié. Scylla est une ré-implémentation open-source de Cassandra en C ++, qui prétend avoir un débit significativement plus élevé et des latences plus faibles que le Cassandra Java d'origine, tout en étant principalement compatible avec lui (dans les fonctionnalités, les API et les formats de fichiers). Donc, si vous envisagez déjà Cassandra, vous pouvez également envisager Scylla.

En discutant avec quelqu'un en train de déployer Cassandra, cela ne gère pas bien le plusieurs-à-plusieurs. Ils font un travail de piratage pour faire leurs premiers tests. J'en ai parlé à un consultant de Cassandra et il a dit qu'il ne le recommanderait pas si ce problème était réglé.

Vous devez vous poser les questions suivantes:

1. (Volume, vitesse) Serez-vous en train d'écrire et de lire des TONNES d'informations, tellement d'informations qu'aucun ordinateur ne pourrait gérer les écritures.
2. (Global) Aurez-vous besoin de cette capacité d'écriture et de lecture à travers le monde pour que les écritures dans une partie du monde soient accessibles dans une autre partie du monde?
3. (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, qu'il s'agisse de VM, de conteneur ou de Bare metal?
4. (Capacité de mise à l'échelle) Avez-vous besoin de cette base de données pour pouvoir continuer à croître facilement et à évoluer de manière linéaire
5. (Cohérence) Avez-vous besoin d'une cohérence TUNABLE où certaines écritures peuvent se produire de manière asynchrone alors que d'autres doivent être certifiées?
6. (Compétence) Êtes-vous prêt à faire ce qu'il faut pour apprendre cette technologie et la modélisation des données qui vont de pair avec la création d'une base de données distribuée mondialement qui peut être rapide pour tout le monde, partout?

Si pour l'une de ces questions vous pensiez «peut-être» ou «non», vous devriez utiliser autre chose. Si vous aviez "enfer oui" comme réponse à tous, alors vous devriez utiliser Cassandra.

Utilisez RDBMS lorsque vous pouvez tout faire sur une seule boîte. C'est probablement plus facile que la plupart et n'importe qui peut travailler avec.

Une seule requête lourde vs une charge de requête légère en gazillions est un autre point à considérer, en plus d'autres réponses ici. Il est intrinsèquement plus difficile d'optimiser automatiquement une seule requête dans une base de données de type NoSql. J'ai utilisé MongoDB et j'ai rencontré des problèmes de performances lors de la tentative de calcul d'une requête complexe. Je n'ai pas utilisé Cassandra mais je m'attends à ce qu'il ait le même problème.

D'un autre côté, si votre charge devrait être celle de très nombreuses petites requêtes et que vous souhaitez pouvoir évoluer facilement, vous pouvez profiter 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 elle est beaucoup plus facile à implémenter et à configurer dans un système basé sur NoSql.

Pour une seule requête très lourde, n'importe quel moteur SGBDR moderne peut faire un travail décent en parallélisant des parties de la requête et profiter d'autant de CPU et de mémoire que vous y jetez (sur une seule machine). Les bases de données NoSql n'ont pas suffisamment d'informations sur la structure des données pour pouvoir faire des hypothèses qui permettront une parallélisation vraiment intelligente d'une grande requête. Ils vous permettent d'évoluer facilement plus de serveurs (ou de cœurs) mais une fois que la requête atteint un niveau de complexité, vous êtes essentiellement obligé de la séparer manuellement en parties que le moteur NoSql sait gérer intelligemment.

D'après mon expérience avec MongoDB, à la fin en raison de la complexité de la requête, Mongo ne pouvait pas faire grand-chose pour l'optimiser et en exécuter des parties sur plusieurs données. Mongo parallélise plusieurs requêtes mais n'est pas si bon pour en 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 db est trop lente.

(Également dû à la validation en 2 phrases, FK, PK)

Cassandra est basée sur du papier Amazon Dynamo

Fonctionnalités:

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.

Depuis 2018,

Je recommanderais d'utiliser ScyllaDB pour remplacer la cassandra classique, si vous avez besoin d'un support arrière.

Le plugin Postgres kv est également plus rapide que cassandra. Cependant, il n'y aura jamais d'évolutivité multi-instance.

Je me concentrerai ici sur certains des aspects importants qui peuvent vous aider à décider si vous avez vraiment besoin de Cassandra. La liste n’est pas exhaustive, juste quelques-uns des points que j’ai en tête

• Ne considérez pas Cassandra comme le premier choix lorsque vous avez une exigence stricte sur la relation (dans votre ensemble de données).

• Cassandra par défaut est 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 le CP. Alors ne l'ignorez pas simplement parce que vous lisez quelque part que c'est AP et que vous recherchez des systèmes CP.Cassandra est plus précisément appelée «syntoniquement cohérente», ce qui signifie qu'elle vous permet de décider facilement du niveau de cohérence dont vous avez besoin, en équilibre avec le niveau de disponibilité.

• N'utilisez pas Cassandra si votre échelle n'est pas grande ou si vous pouvez gérer une base de données non distribuée.

• Réfléchissez bien 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 l'optimiser et le maîtriser pour résoudre un problème spécifique nécessiterait une bonne (sinon beaucoup) d'effort d'ingénierie.

• Cassandra est orientée colonne, mais en même temps, chaque ligne a également une clé unique. Il peut donc être utile de le considérer comme un magasin indexé et orienté lignes. Vous pouvez même l'utiliser comme magasin de documents.

• Cassandra ne vous oblige pas à définir les champs au préalable. Donc, si vous êtes en mode démarrage ou que vos fonctionnalités évoluent (comme en agile) - Cassandra l'adopte. Donc mieux, pensez d'abord aux requêtes, puis pensez aux données pour y répondre.

• Cassandra est optimisée pour un débit d'écriture très élevé. Si votre cas d'utilisation est lourd en lecture (comme le cache), Cassandra n'est peut-être pas un choix idéal.

une autre situation qui facilite le choix est lorsque vous souhaitez utiliser une fonction d'agrégation comme sum, min, max, etcetera et des requêtes complexes (comme dans le système financier mentionné ci-dessus), alors une base de données relationnelle est probablement plus pratique qu'une base de données nosql car les deux sont impossible sur une base de données nosql sauf si vous utilisez vraiment beaucoup d'index inversés. Lorsque vous utilisez nosql, vous devez effectuer les fonctions d'agrégation dans le code ou les stocker séparément dans sa propre famille de colonnes, mais cela rend tout assez complexe et réduit les performances que vous avez obtenues en utilisant nosql.

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 valeurs-clés. Il ne prend pas en charge les requêtes SQL. Les données de Cassandra sont "finalement cohérentes". Les recherches simultanées de données peuvent être incohérentes, mais finalement les recherches sont cohérentes.

Si vous avez besoin d'une sémantique stricte et avez besoin de support pour les requêtes SQL, choisissez une autre solution telle que MySQL, PostGres, ou combinez l'utilisation de Cassandra avec Solr.

Cassandra est un bon choix si:

1. Vous n'avez pas besoin des propriétés ACID de votre base de données.

2. Il y aurait un nombre énorme et énorme d'écritures sur la base de données.

3. Il est nécessaire d'intégrer avec Big Data, Hadoop, Hive et Spark.

4. Il est nécessaire d'analyser les données en temps réel et de générer des rapports.

5. Il faut un mécanisme de tolérance aux pannes impressionnant.

6. Il y a une exigence de système homogène.

7. Il y a une exigence de beaucoup de personnalisation pour le réglage.

Mongodb a des fonctions d'agrégation très puissantes et un cadre d'agrégation expressif. Il possède de nombreuses fonctionnalités que les développeurs ont l'habitude d'utiliser dans 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 s'accompagne bien sûr de compromis. Ainsi, lorsque vous sélectionnez votre base de données (NoSQL, NewSQL ou RDBMS), examinez le problème que vous essayez de résoudre et vos besoins d'évolutivité. Aucune base de données ne fait tout.

Selon DataStax, Cassandra n'est pas le meilleur cas d'utilisation lorsqu'il y a un besoin de

1- Périphériques matériels haut de gamme. 2- Conforme ACID sans roll back (transaction bancaire)

• Il ne prend pas en charge la gestion complète des transactions entre les tables.
• Index secondaire non pris en charge.
• Vous devez compter sur Elastic search / Solr pour l'index secondaire et le composant de synchronisation personnalisé doit être écrit.
• Système non conforme ACID.
• La prise en charge des requêtes est limitée.

Apache cassandra est une base de données distribuée pour 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 aucun point de défaillance unique.

L'archichecture est purement basée sur le théorème du capuchon, qui est la disponibilité et la tolérance de partition, et de manière intéressante finalement, de manière cohérente.

Ne l'utilisez pas, si vous ne stockez pas de volumes de données sur des racks de clusters, ne l'utilisez pas si vous ne stockez pas de données de série chronologique, ne l'utilisez pas si vous ne patitionnez pas vos serveurs, ne l'utilisez pas si vous avez besoin d'une cohérence élevée.