Waarom velen verwijzen naar Cassandra als een kolomgerichte database?

Verschillende papieren en documenten op internet lezen, vond ik veel tegenstrijdige informatie over het Cassandra-gegevensmodel. Er zijn veel die het identificeren als een kolomgeoriënteerde database, anders als een rij-georiënteerd en dan die het definiëren als een hybride manier van beide.

Volgens wat ik weet over hoe Cassandra Stores-bestand, gebruikt het het * -index.db-bestand om toegang te krijgen tot de juiste positie van het bestand * -data.db waar het de bloeifilter, de kolomindex en vervolgens is opgeslagen kolommen van de vereiste rij.

Naar mijn mening is dit strikt rij-georiënteerd. Is er iets dat ik mis?

Antwoord 1, Autoriteit 100%

• Als u een kijkje neemt naar het Readme -bestand op Apache Cassandra Git Repo , het zegt dat,

Cassandra is een gepartitioneerde rijwinkel. Rijen worden georganiseerd in tafels
met een vereiste primaire sleutel.

partitionering betekent dat Cassandra uw gegevens kan verspreiden
meerdere machines in een applicatie-transparante materie. Cassandra zal
automatisch repartitioneren als machines worden toegevoegd en verwijderd van de
cluster.

Rijwinkel betekent dat als relationele databases, Cassandra organiseert
gegevens per rijen en kolommen.

• Column Oriented of Columnar-databases worden op schijfkolom opgeslagen.

  E.G: Tabel BonusesTabel

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

• In een rij-georiënteerd databasebeheersysteem, zouden de gegevens als volgt worden opgeslagen: 1,Doe,John,8000;2,Smith,Jane,4000;3,Beck,Sam,1000;

• In een kolomgericht databasebeheersysteem, zouden de gegevens als volgt worden opgeslagen:
  1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;

• Cassandra is eigenlijk een kolomfamilie opslaan

• Cassandra zou de bovenstaande gegevens opslaan als,

    "Bonuses" : {
           row1 : { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000},
           row2 : { "ID":2, "Last":"Smith", "First":"Jane", "Bonus":4000}
           ...
     }

• Ook het aantal kolommen in elke rij moet niet hetzelfde zijn. Eén rij kan 100 kolommen hebben en de volgende rij kan slechts 1 kolom hebben.

• Lees dit voor Meer details.

Antwoord 2, Autoriteit 78%

Ja, de “kolomgerichte” terminologie is een beetje verwarrend.

Het model in Cassandra is dat rijen kolommen bevatten. Om toegang te krijgen tot de kleinste eenheid van gegevens (een kolom) moet u eerst de rij-naam (toets) opgeven, vervolgens de kolomnaam.

Dus in een kolomfamilie genaamd FruitU kunt een structuur hebben zoals het volgende voorbeeld (met 2 rijen), waarbij de fruittypen de rijtoetsen zijn en de kolommen elk een naam en waarde hebben.

apple -> colour  weight  price variety
         "red"   100     40    "Cox"
orange -> colour    weight  price  origin
          "orange"  120     50     "Spain"

Eén verschil van een op tafel gebaseerde relationele database is dat men kolommen kan weglaten (oranje heeft geen variëteit) of wenst willekeurige kolommen (Orange heeft oorsprong) op elk moment. Je kunt je nog steeds de bovenstaande gegevens voorstellen als een tabel, zij het een schaarse waarvan veel waarden leeg kunnen zijn.

Een model van de kolomgerichte “kan echter ook worden gebruikt voor lijsten en tijdreeksen, waarbij elke kolomnaam uniek is (en hier hebben we slechts één rij, maar we zouden duizenden of miljoenen kolommen kunnen hebben):

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

die heel anders is dan een relationeel model, waarbij men de vermeldingen van een tijdreeks moet modelleren als rowsniet columns. Dit type gebruik wordt vaak “brede rijen” genoemd.

Antwoord 3, autoriteit 14%

Jullie maken allebei goede punten en het kan verwarrend zijn. In het voorbeeld waar

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

appel is de sleutelwaarde en de kolom is de data, die alle 4 data-items bevat. Uit wat werd beschreven, klinkt het alsof alle 4 gegevensitems samen als een enkel object worden opgeslagen en vervolgens door de toepassing worden geparseerd om alleen de vereiste waarde te halen. Daarom moet ik vanuit een IO-perspectief het hele object lezen. IMHO is dit inherent op rij (of object) gebaseerd, niet op kolommen.

Op kolommen gebaseerde opslag werd populair voor warehousing, omdat het extreme compressie en verminderde IO biedt voor volledige tabelscans (DW), maar ten koste van een hogere IO voor OLTP wanneer u elke kolom moest ophalen (selecteer *). De meeste query’s hebben niet elke kolom nodig en door compressie kan de IO sterk worden verminderd voor volledige tabelscans voor slechts een paar kolommen. Laat me een voorbeeld geven

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

We hebben twee verschillende soorten fruit, maar beide hebben een kleur = rood. Als we kleur opslaan op een aparte schijfpagina (blok) van gewicht, prijs en variëteit, zodat het enige dat wordt opgeslagen kleur is, dan kunnen we extreme compressie bereiken als we de pagina comprimeren vanwege veel deduplicatie. In plaats van 100 rijen (hypothetisch) op een pagina op te slaan, kunnen we 10.000 kleuren opslaan. Om nu alles met de kleur rood te lezen, is het misschien 1 IO in plaats van duizenden IO’s, wat echt goed is voor warehousing en analyse, maar slecht voor OLTP als ik de hele rij moet bijwerken, omdat de rij honderden kolommen en een enkele kan hebben update (of insert) kan honderden IO’s vereisen.

Tenzij ik iets mis dat ik dit niet op kolommen gebaseerd zou noemen, zou ik het objectgebaseerd noemen. Het is nog steeds niet duidelijk hoe objecten op schijf zijn gerangschikt. Zijn er meerdere objecten op dezelfde schijfpagina geplaatst? Is er een manier om ervoor te zorgen dat objecten met dezelfde metadata bij elkaar passen? Is er een manier om ervoor te zorgen dat bepaalde overeenkomende fruitsoorten samen worden opgeslagen om de efficiëntie te verhogen?

p>

Larry

Antwoord 4, autoriteit 13%

De meest eenduidige term die ik ben tegengekomen is wide-column store.

Het is een soort tweedimensionale sleutel/waarde-opslag, waarbij je een rijsleutel en een kolomsleutel gebruikt om toegang te krijgen tot gegevens.

Het belangrijkste verschil tussen dit model en de relationele (zowel rijgericht als kolomgericht) is dat de kolominformatie deel uitmaakt van de gegevens.

Dit houdt in dat gegevens schaarskunnen zijn. Dat betekent dat verschillende rijen niet dezelfde kolomnamen of hetzelfde aantal kolommen hoeven te delen. Dit maakt semi-gestructureerde gegevens of schemavrije tabellen mogelijk.

Je kunt winkels met brede kolommen zien als tabellen die een onbeperkt aantal kolommen kunnen bevatten, en dus breed zijn.

Hier zijn een paar links om dit te staven:

• Dit mongodb-artikel
• Dit Datastax-artikelvermeldt het ook, hoewel Cassandra wordt geclassificeerd als een winkel met sleutelwaarde.
• Dit db-engines-artikel
• Dit artikel uit 2013
• Wikipedia

Antwoord 5, autoriteit 9%

Kolomfamilie betekent niet dat het kolomgericht is. Cassandra is een kolomfamilie, maar niet kolomgericht. Het slaat de rij op met al zijn kolomfamilies bij elkaar.

Hbase is kolomfamilie en slaat kolomfamilies op kolomgeoriënteerde wijze op. Verschillende kolomfamilies worden afzonderlijk opgeslagen in een knooppunt of ze kunnen zelfs in een ander knooppunt verblijven.

Antwoord 6, autoriteit 5%

IMO dat is de verkeerde term voor Cassandra. In plaats daarvan is het beter om het een row-partitionstore te noemen. Ik zal je er wat details over geven:

Primaire sleutel, partitiesleutel, clusterkolommen en gegevenskolommen:

Elke tabel moet een primaire sleutel met een unieke beperking hebben.

Primary Key = Partition key + Clustering Columns
# Example
Primary Key: ((col1, col2), col3, col4)     # primary key uniquely identifies a row
                                            # we need to choose its components partition key
                                            # and clustering columns so that each row can be
                                            # uniquely identified
Partition Key: (col1, col2)                 # decides on which node to store the data
                                            # partitioning key is mandatory, and it
                                            # can be made up of one column or multiple
Clustering Columns: col3, col4              # decides arrangement within a partition
                                            # clustering columns are optional

Partitiesleutelis het eerste onderdeel van de primaire sleutel. De gehashte waarde wordt gebruikt om het knooppunt te bepalen om de gegevens op te slaan. De partitiesleutel kan een samengestelde sleutel zijn die uit meerdere kolommenbestaat. We willen bijna gelijke gegevensspreidingenen we houden hier rekening mee bij het kiezen van de primaire sleutel.

Alle velden die na de partitiesleutel in de primaire sleutel worden vermeld, worden Clusteringkolommengenoemd. Deze slaan gegevens op in oplopende volgorde binnen de partitie. De component van de clusterkolom helpt ook om ervoor te zorgen dat de primaire sleutel van elke rij uniek is.

U kunt zoveel clusterkolommen gebruiken als u wilt. U kunt de clusteringkolommen niet in de verkeerde volgorde gebruiken in de SELECT-instructie. U kunt ervoor kiezen om het gebruik van een clusterkolom in uw SELECT-instructie weg te laten. Dat is oke. Vergeet niet om ze op volgorde aan te klagen wanneer u de SELECT-instructie gebruikt. Houd er echter rekening mee dat u in uw CQL-query niet kunt proberen toegang te krijgen tot een kolom of een clusterkolom als u de andere gedefinieerde clusteringkolommen niet hebt gebruikt. Als de primaire sleutel bijvoorbeeld (year, artist_name, album_name)is en u de kolom citywilt gebruiken in de WHERE-clausule van uw zoekopdracht, dan kan het alleen gebruiken als uw WHERE-clausule alle kolommen gebruikt die deel uitmaken van de primaire sleutel.

Tokens:

Cassandra gebruikt tokensom te bepalen welk knooppunt welke gegevens bevat. Een token is een 64-bits geheel getal en Cassandra wijst reeksen van deze tokens toe aan knooppunten, zodat elk mogelijk token eigendom is van een knooppunt. Door meer knooppunten aan het cluster toe te voegen of oude te verwijderen, worden deze token opnieuw onder knooppunten verdeeld.

De partitiesleutelvan een rij wordt gebruikt om een ​​token te berekenen met behulp van een bepaalde partitioner (een hashfunctie voor het berekenen van het token van een partitiesleutel) om te bepalen welk knooppunt eigenaar is van die rij.

Cassandra is Row-partition store:

Rij is de kleinste eenheid die gerelateerde gegevens in Cassandra opslaat.

Beschouw Cassandra’s kolomfamilie (dat wil zeggen, tafel)niet als een RDBMS-tabel, maar beschouw het als een dictvan a dict(hier is dicteen datastructuur vergelijkbaar met OrderedDictvan Python):

• de buitenste dictwordt gecodeerd door een rijsleutel (primaire sleutel): deze bepaalt welke partitie en welke rij in partitie
• het binnenste dictwordt gecodeerd door een kolomsleutel (gegevenskolommen): dit zijn gegevens in dictmet kolomnamen als sleutels
• beide dictzijn geordend (op sleutel) en gesorteerd: het buitenste dictis gesorteerd op primaire sleutel

Met dit model kunt u op elk gewenst moment kolommen weglatenof willekeurige kolommentoevoegen, omdat u verschillende gegevenskolommen voor verschillende rijen kunt hebben.

Antwoord 7, Autoriteit 2%

Cassandra heeft een concept van kolomfamilies (tabel), die oorspronkelijk uit bigtable komt. Hoewel het echt misleidend is om ze kolomgericht te maken zoals genoemd. Binnen elke kolomfamilie bewaren ze alle kolommen van een rij samen, samen met een rij-toets, en ze gebruiken geen kolomcompressie. Het bigtable-model is dus nog steeds meestal rij-georiënteerd.