Devrait probablement être CW? Il s'agit à peu près des bases de données NoSQL vs relationnelles, ce qui est assez subjectif IMO.
Ed James
3
Je voudrais savoir s'il convient au système de messagerie. Je suppose que si Twitter l'utilise, ce serait bien, mais ils pourraient ne pas l'utiliser pour tout Twitter?
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.
Le problème avec la réponse est qu'elle regroupe toutes les solutions NoSQL ensemble. Voir dataconomy.com/sql-vs-nosql-need-know pour plus d'informations. Dans le paysage NoSQL, les divisions de base sont document, valeur-clé, graphique et grand tableau. Ils ont des caractéristiques différentes pour différents problèmes. Une solution qui convient bien à la mongo peut ne pas convenir à la cassandra.
Yehosef
17
La seule façon dont cette réponse "regroupe toutes les solutions NoSQL ensemble" est par la catégorie NoSQL; à part cela, la publication fait un excellent travail en soulignant que chaque base de données NoSQL "offre une solution différente" pour différents problèmes. Je n'ai pas eu le sentiment que l'auteur avait même laissé entendre que mongo, cassandra ou toute autre base de données NoSQL résolvaient les mêmes problèmes.
Nick Suwyn
NoSQL databasen'est pas une chose. NoSQLest juste un terme utilisé pour les bases de données non relationnelles modernes (voir wiki ).
eddyP23
2
Notez également que toutes les bases de données NoSQL ne sont pas ACID. Les BD de graphiques sont généralement ACID.
eddyP23
Cassandra prend en charge le fonctionnement atomique au niveau des lignes et Atomic et Isolation par partition à l'aide de transactions de poids léger. Si mon exigence est d'avoir ACID au niveau de la ligne, ne puis-je pas utiliser Cassandra? Même pour les données critiques?
TechEnthusiast
52
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 .
À quand remonte la dernière fois que vous avez vu une partition où les deux partitions étaient grandes? Voir ma question stackoverflow.com/questions/7969874/…
Aaron Watters
5
Cassandra vous permet également de spécifier votre exigence de cohérence au moment de la requête, ce qui peut être un compromis utile pour certains cas d'utilisation
Richard Marr
30
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.
Il est peu probable que le schéma change, il s'intègre bien dans une structure de table et les données perdues / incohérentes peuvent provoquer de réels problèmes.
Tom Clarkson
4
Je ne comprends pas pourquoi des données incohérentes peuvent causer de réels problèmes avec les banques. Scénario: vous avez un compte bancaire avec 100 $ au-dessus de la limite et deux cartes bancaires. Lorsque vous essayez de retirer de l'argent avec les deux cartes en même temps à 2 distributeurs automatiques différents, vous recevrez 2 fois 100 $ et une lettre avec des frais supplémentaires dans votre boîte aux lettres. La banque gagne de l'argent (les frais supplémentaires pour être en dessous de la limite) en utilisant des données incohérentes. Il est difficile de connecter tous les guichets automatiques du monde entre eux via une grande base de données relationnelle. Pouvez-vous donner un exemple où des données financières incohérentes peuvent être un problème?
Paco
5
Ce truc est entièrement COBOL et traitement par lots, et pas aussi bien conçu / stable que vous ne le pensez. Les guichets automatiques ne se connectent à aucune sorte de magasin de données unifié, ils ne sont donc pas un exemple approprié. C'est comme dire que SQL n'est pas adapté aux applications Web, car vous ne pouvez pas donner à tout le monde sur Internet un accès direct à votre base de données. De plus, je n'ai jamais rien dit sur les banques - pensez à des choses comme les commandes sur un site de commerce électronique où vous n'avez pas à traiter avec une organisation si conservatrice que SQL est considéré comme nouveau et non fiable.
Tom Clarkson
6
@Paco: Le premier guichet automatique lit votre solde (100 $), et le deuxième guichet automatique fait de même. Les deux guichets automatiques déduisent 100 $ de 100 $ et réinscrivent le solde final de 0 $ sur votre compte. Résultat: la banque perd 100 $.
Seun Osewa
9
@Paco: Le fait est que, sans isolement approprié des transactions, la banque normale ne saura même pas que le compte a été dépassé. Ils ne sauront même pas.
Seun Osewa
14
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é.
(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.
(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?
(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?
(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
(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?
(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.
Vous n'avez pas à vous contenter d'une seule technologie de base de données. Vous pouvez réellement avoir un combo et utiliser celui qui est approprié pour le problème spécifique.
Pepito Fernandez du
3
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.
CouchdB, pour sa part, permet de calculer très facilement les fonctions d'agrégation: wiki.apache.org/couchdb/… . Techniquement, c'est "dans le code" mais ce n'est pas aussi "complexe" à accomplir qu'avec Cassandra.
user359996
2
En fait, je conviens que cela peut prendre un jour pour écrire des agrégats dans le code, mais vous pouvez l'écrire pour l'exécuter sur un serveur principal qui utilisera près de 0 cycles de la base de données. Avec une base de données SQL, vous obtiendrez le résultat en écrivant une ligne, ce qui peut vous prendre 5 minutes. mais cela ralentira toute la base de données chaque fois que vous l'exécuterez. Il y a donc des avantages et des inconvénients dans les deux sens. Ma banque, par exemple, ferme tous les accès au site Web au milieu de la nuit pendant environ 10 à 15 minutes. Ils utilisent certainement COBOL, mais c'est un problème très similaire.
Alexis Wilke
1
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.
Le langage de requête Cassandra (CQL) est assez similaire à SQL, cependant. En fait, je dirais que CQL est un avantage de Cassandra sur les autres options NoSQL pour ceux qui recherchent une interface de type SQL.
arussell84
1
Cassandra n'est finalement pas cohérente sur le plan technique. Cassandra vous permet de compromis la cohérence pour la disponibilité. Cassandra équilibre fondamentalement le théorème de CAP. Vous pouvez éventuellement avoir une écriture cohérente, puis lire de manière cohérente, vice versa, ou cohérente sur les deux, et tout cela dépend de votre facteur de réplication combiné à votre niveau de lecture / écriture. J'obtiens que la réponse a mis "éventuellement cohérent" entre guillemets, probablement pour cette raison, mais j'ai l'impression qu'une certaine clarté s'impose.
tsturzl
1
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 avec Big Data, Hadoop, Hive et Spark.
Il est nécessaire d'analyser les données en temps réel et de générer des rapports.
Il faut un mécanisme de tolérance aux pannes impressionnant.
Il y a une exigence de système homogène.
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.
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.
Réponses:
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.
la source
NoSQL databasen'est pas une chose.NoSQLest juste un terme utilisé pour les bases de données non relationnelles modernes (voir wiki ).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 .
la source
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.
la source
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.
la source
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.
la source
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é.
la source
Vous devez vous poser les questions suivantes:
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.
la source
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.
la source
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:
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.
la source
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.
la source
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.
la source
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.
la source
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 avec Big Data, Hadoop, Hive et Spark.
Il est nécessaire d'analyser les données en temps réel et de générer des rapports.
Il faut un mécanisme de tolérance aux pannes impressionnant.
Il y a une exigence de système homogène.
Il y a une exigence de beaucoup de personnalisation pour le réglage.
la source
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.
la source
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)
la source
la source
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.
la source