web-dev-qa-db-fra.com

Pourquoi beaucoup se réfèrent à Cassandra comme une base de données orientée colonne?

En lisant plusieurs articles et documents sur Internet, j'ai trouvé de nombreuses informations contradictoires sur le modèle de données Cassandra. Il y en a beaucoup qui l'identifient comme une base de données orientée colonne, d'autres comme une ligne orientée et qui définissent ensuite comme un moyen hybride des deux.

Selon ce que je sais sur la façon dont Cassandra stocke le fichier, il utilise le fichier * -Index.db pour accéder à la bonne position du fichier * -Data.db où il est stocké le filtre de floraison , l'index de colonne, puis les colonnes de la ligne requise.

À mon avis, c'est strictement axé sur les lignes. Y a-t-il quelque chose qui me manque?

cassandranosqldata-modelingcolumn-oriented
47
cesare

Oui, la terminologie "orientée colonne" est un peu déroutante.

Le modèle dans Cassandra est que les lignes contiennent des colonnes. Pour accéder à la plus petite unité de données (une colonne), vous devez d'abord spécifier le nom de la ligne (clé), puis le nom de la colonne.

Ainsi, dans une famille de colonnes appelée Fruit, vous pourriez avoir une structure comme l'exemple suivant (avec 2 lignes), où les types de fruits sont les clés de ligne et les colonnes ont chacune un nom et une valeur.

Apple -> colour  weight  price variety
         "red"   100     40    "Cox"

orange -> colour    weight  price  Origin
          "orange"  120     50     "Spain"

Une différence par rapport à une base de données relationnelle basée sur une table est que l'on peut omettre des colonnes (orange n'a pas de variété), ou ajouter des colonnes arbitraires (orange a Origin) à tout moment. Vous pouvez toujours imaginer les données ci-dessus sous forme de tableau, quoique clairsemé où de nombreuses valeurs peuvent être vides.

Cependant, un modèle "orienté colonne" peut également être utilisé pour les listes et les séries chronologiques, où chaque nom de colonne est unique (et ici nous n'avons qu'une seule ligne, mais nous pourrions avoir des milliers ou des millions de colonnes):

temperature ->  2012-09-01  2012-09-02  2012-09-03 ...
                40          41          39         ...

ce qui est assez différent d'un modèle relationnel, où il faudrait modéliser les entrées d'une série temporelle comme rows pas columns. Ce type d'utilisation est souvent appelé "lignes larges".

52
DNA

Cassandra est un magasin en ligne partitionné. Les lignes sont organisées en tables avec une clé primaire requise.

Le partitionnement signifie que Cassandra peut distribuer vos données sur plusieurs machines de manière transparente pour l'application. Cassandra se repartitionnera automatiquement lorsque les machines seront ajoutées et supprimées du cluster).

Le magasin de lignes signifie que, comme les bases de données relationnelles, Cassandra organise les données par lignes et colonnes.

  • Les bases de données orientées ou en colonnes sont stockées sur le disque en fonction des colonnes.

    par exemple: Table Bonuses table

     ID         Last    First   Bonus
 1          Doe     John    8000
 2          Smith   Jane    4000
 3          Beck    Sam     1000

  • Dans un système de gestion de base de données orienté lignes , les données seraient stockées comme suit: 1,Doe,John,8000;2,Smith,Jane,4000;3,Beck,Sam,1000;

  • Dans un système de gestion de base de données orienté colonne , les données seraient stockées comme suit:
    1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;

  • Cassandra est fondamentalement un magasin de familles de colonnes

  • Cassandra stockerait les données ci-dessus sous la forme, "Bounses" : { row1 : { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000}, row2 : { "ID":2, "Last":"Smith", "First":"Jane", "Bonus":4000} ... }
  • Lisez ceci pour plus de détails.

J'espère que cela t'aides.

42
tharindu_DG

Vous faites tous les deux de bons arguments et cela peut être déroutant. Dans l'exemple où

Apple -> colour  weight  price variety
         "red"   100     40    "Cox"

Apple est la valeur clé et la colonne est les données, qui contiennent les 4 éléments de données. D'après ce qui a été décrit, il semble que les 4 éléments de données soient stockés ensemble comme un seul objet puis analysés par l'application pour extraire uniquement la valeur requise. Par conséquent, d'un point de vue IO, j'ai besoin de lire l'intégralité de l'objet. À mon humble avis, c'est intrinsèquement basé sur une ligne (ou un objet) et non sur une colonne.

Le stockage basé sur colonnes est devenu populaire pour l'entreposage, car il offre une compression extrême et une réduction IO pour les analyses de table complètes (DW) mais au prix d'une augmentation IO for = OLTP lorsque vous avez dû extraire chaque colonne (sélectionnez *). La plupart des requêtes n'ont pas besoin de chaque colonne et en raison de la compression, le IO peut être considérablement réduit pour être complet) table analyse quelques colonnes seulement. Permettez-moi de vous donner un exemple

Apple -> colour  weight  price variety
         "red"   100     40    "Cox"

grape -> colour  weight  price variety
         "red"   100     40    "Cox"

Nous avons deux fruits différents, mais les deux ont une couleur = rouge. Si nous stockons la couleur dans une page de disque (bloc) distincte du poids, du prix et de la variété, la seule chose stockée est la couleur, alors lorsque nous compressons la page, nous pouvons obtenir une compression extrême en raison de beaucoup de déduplication. Au lieu de stocker (hypothétiquement) 100 lignes dans une page, nous pouvons stocker 10 000 couleurs. Maintenant, pour tout lire avec la couleur rouge, cela pourrait être 1 IO au lieu de milliers d'E/S, ce qui est vraiment bon pour l'entreposage et l'analyse, mais mauvais pour OLTP si Je dois mettre à jour la ligne entière car la ligne peut avoir des centaines de colonnes et une seule mise à jour (ou insertion) peut nécessiter des centaines d'E/S.

À moins que je manque quelque chose que je n'appellerais pas basé sur des colonnes, je l'appellerais basé sur des objets. On ne sait toujours pas comment les objets sont organisés sur le disque. Plusieurs objets sont-ils placés sur la même page de disque? Existe-t-il un moyen de s'assurer que les objets avec les mêmes métadonnées vont ensemble? Au point qu'un fruit peut contenir des données différentes d'un autre fruit puisque ses seules métadonnées ou xml ou tout ce que vous souhaitez stocker dans l'objet lui-même, existe-t-il un moyen de s'assurer que certains types de fruits correspondants sont stockés ensemble pour augmenter l'efficacité?

Larry

11
user2615236

La famille de colonnes ne signifie pas qu'elle est orientée sur les colonnes. Cassandra est une famille de colonnes mais pas orientée sur les colonnes. Elle stocke la ligne avec toutes ses familles de colonnes ensemble.

Hbase est une famille de colonnes et stocke les familles de colonnes de manière orientée colonnes. Différentes familles de colonnes sont stockées séparément dans un nœud ou peuvent même résider dans un nœud différent.

5
SASANKA GHOSH

Le terme le plus clair que j'ai rencontré est magasin à colonnes larges .

Il s'agit d'une sorte de magasin de valeurs-clés bidimensionnel , dans lequel vous utilisez une clé de ligne et une clé de colonne pour accéder aux données.

La principale différence entre ce modèle et les modèles relationnels (orientés ligne et colonne) est que les informations de colonne font partie des données .

Cela implique que les données peuvent être clairsemées . Cela signifie que différentes lignes n'ont pas besoin de partager les mêmes noms de colonnes ni le nombre de colonnes. Cela permet des données semi-structurées ou des tables sans schéma.

Vous pouvez considérer les magasins à colonnes larges comme des tables pouvant contenir un nombre illimité de colonnes et donc larges.

Voici quelques liens pour sauvegarder cela:

5
Jens