Dlaczego wielu odnosi się do Cassandry jako bazy danych zorientowanej na kolumnę?

Question

Czytając kilka dokumentów i dokumentów w Internecie, znalazłem wiele sprzecznych informacji na temat modelu danych Cassandra. Jest wiele takich, które identyfikują ją jako bazę danych zorientowaną na kolumny, inne jako zorientowane na rząd, a następnie definiują ją jako hybrydowy sposób obu.

Zgodnie z tym, co wiem o tym, jak Cassandra przechowuje plik, używa pliku * -Index.db w celu uzyskania dostępu do właściwej pozycji pliku * -Data.db, w którym jest przechowywany filtr kwitnienia, indeks kolumny, a następnie kolumny wymaganego wiersza.

Moim zdaniem jest to ściśle ukierunkowane na rząd. Czy jest coś, czego mi brakuje?

Answer 1

Tak, terminologia "zorientowana na kolumnę" jest nieco myląca.

Model w Cassanderze polega na tym, że wiersze zawierają kolumny. Aby uzyskać dostęp do najmniejszej jednostki danych (kolumna), musisz najpierw podać nazwę (klucz), a następnie nazwę kolumny.

Tak więc w rodzinie kolumn o nazwie Fruit możesz mieć strukturę podobną do poniższego przykładu (z 2 wierszami), gdzie typy owoców są kluczami wierszy, a każda kolumna ma nazwę i wartość.

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

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

Różnica z relacyjnej bazy danych opartej na tabeli jest to, że można pominąć kolumn (pomarańczowy ma różne) lub dodać dowolne kolumny (pomarańczowy ma pochodzenie) w dowolnym momencie. Nadal możesz sobie wyobrazić powyższe dane jako tabelę, choć rzadką, gdy wiele wartości może być pustych.

Jednak model "zorientowany na kolumny" może być również użyty dla list i szeregów czasowych, gdzie każda nazwa kolumny jest unikalna (i tutaj mamy tylko jeden wiersz, ale mogliśmy mieć tysiące lub miliony kolumn):

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

który jest zupełnie inny od modelu relacyjnego, gdzie trzeba by modelować wpisy z szeregu czasowego jako rows nie columns.

Answer 2

Oboje macie dobre punkty i to może być mylące. W przykładzie, w którym jabłko jest wartością kluczową, kolumna jest danymi, które zawierają wszystkie 4 elementy danych. Z tego, co zostało opisane, wynika, że ​​wszystkie 4 elementy danych są przechowywane razem jako pojedynczy obiekt, a następnie analizowane przez aplikację w celu pobrania wymaganej wartości. Dlatego z perspektywy IO muszę przeczytać cały obiekt. IMHO jest to z natury wiersz (lub obiekt) oparty nie na kolumnie.

Przechowywanie w oparciu o kolumnę stało się popularne w przypadku magazynowania, ponieważ oferuje ekstremalną kompresję i zmniejszone IO dla pełnych skanów tabeli (DW), ale kosztem zwiększenia IO dla OLTP, kiedy trzeba było wyciągnąć każdą kolumnę (wybierz *). Większość zapytań nie potrzebuje każdej kolumny, a ze względu na kompresję IO można znacznie zredukować do pełnych skanów tabel tylko dla kilku kolumn. Pozwól mi podać przykład:

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

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

Mamy dwa różne owoce, ale oba mają kolor = czerwony. Jeśli przechowujemy kolory na oddzielnej stronie dysku (bloku) od wagi, ceny i odmiany, jedyną rzeczą przechowywaną jest kolor, a kiedy skompresujemy stronę, możemy osiągnąć ekstremalną kompresję z powodu dużej ilości duplikacji. Zamiast przechowywać 100 wierszy (hipotetycznie) na stronie, możemy przechowywać 10 000 kolorów.Teraz, aby przeczytać wszystko z kolorem czerwonym, może to być 1 IO zamiast tysięcy IO, co jest naprawdę dobre dla magazynowania i analizowania, ale złe dla OLTP, jeśli muszę zaktualizować cały wiersz, ponieważ wiersz może mieć setki kolumn i jeden update (lub insert) może wymagać setek IO.

Chyba że czegoś mi brakuje, nie nazwałbym tego opartego na kolumnach, nazwałbym to obiektowym. Nadal nie jest jasne, w jaki sposób obiekty są rozmieszczone na dysku. Czy wiele obiektów umieszczonych jest na tej samej stronie dysku? Czy istnieje sposób zapewnienia, że ​​obiekty o tych samych danych meta idą w parze? Do tego stopnia, że ​​jeden owoc może zawierać inne dane niż inny owoc, ponieważ jego tylko meta dane lub xml lub cokolwiek chcesz przechowywać w samym obiekcie, czy istnieje sposób na zapewnienie, aby pewne pasujące typy owoców były przechowywane razem, aby zwiększyć wydajność?

Larry

Answer 3

• Jeśli spojrzeć na pliku Readme w Apache Cassandra git repo, to mówi, że

Cassandra jest partycjonowana sklep rząd. Wiersze są uporządkowane w tabele z wymaganym kluczem podstawowym.

Partycjonowanie oznacza, że ​​Cassandra może dystrybuować twoje dane przez wielu maszyn w przejrzystej aplikacji. Cassandra będzie automatycznie repartycjonować, gdy maszyny zostaną dodane i usunięte z klastra .

Magazyn wierszy oznacza, że ​​podobnie jak relacyjne bazy danych, Cassandra porządkuje dane według wierszy i kolumn.

• Kolumna zorientowany lub kolumnowych baz danych są zapisywane na dysku kolumny mądry.

  np Tabela Bonuses tabeli

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

• w systemie zarządzania rzędu zorientowane bazy danych, dane powinny być zapisywane w następujący sposób: 1,Doe,John,8000;2,Smith,Jane,4000;3,Beck,Sam,1000;

• W zorientowane kolumny system zarządzania bazami danych, dane będą przechowywane w następujący sposób:
  1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;

• Cassandra jest w zasadzie kolumna mieszkaniami sklep

• Cassandra będzie przechowywać dane jak wyżej, "Bounses" : { row1 : { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000}, row2 : { "ID":2, "Last":"Smith", "First":"Jane", "Bonus":4000} ... }
• Czytaj this więcej szczegółów.

Mam nadzieję, że to pomoże.

Answer 4

Rodzina kolumn nie oznacza, że ​​jest zorientowana na kolumny. Cassandra jest rodziną kolumnową, ale nie kolumnową. Przechowuje wiersz razem ze wszystkimi rodzinami kolumn.

Hbase to rodzina kolumn, a także przechowuje rodziny kolumn w sposób zorientowany na kolumnę. Różne rodziny kolumn są przechowywane oddzielnie w węźle lub mogą nawet znajdować się w innym węźle.