4.1 Opis

Apache Cassandra to system zarządzania rozproszonymi bazami danych należący do klasy systemów NoSQL i przeznaczony do tworzenia wysoce skalowalnych i niezawodnych magazynów ogromnych tablic danych prezentowanych w postaci skrótu.

Początkowo projekt rozwijany był w trzewiach Facebooka, aw 2009 roku przekazany pod skrzydła Apache Software Foundation, organizacja ta nadal rozwija projekt. Rozwiązania przemysłowe oparte na Cassandrze są wdrażane do świadczenia usług dla takich firm jak Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Huawei, Netflix, Apple, Instagram, GitHub, Twitter czy Spotify. Do 2011 roku największy klaster serwerów obsługujący pojedynczą bazę danych pod kontrolą Cassandry miał ponad 400 maszyn i zawierał ponad 300 TB danych.

Napisany w języku Java implementuje rozproszony system mieszania podobny do DynamoDB, który zapewnia niemal liniową skalowalność wraz ze wzrostem ilości danych. Wykorzystuje model przechowywania danych oparty na rodzinie kolumn, który różni się od systemów takich jak MemcacheDB, które przechowują dane tylko w parze klucz-wartość, możliwością przechowywania hashów z kilkoma poziomami zagnieżdżenia.

Należy do kategorii fault-tolerant DBMS: dane umieszczone w bazie danych są automatycznie replikowane do kilku węzłów rozproszonej sieci lub nawet równomiernie rozmieszczone w kilku centrach danych. Kiedy węzeł ulegnie awarii, jego funkcje są pobierane w locie przez inne węzły, dodawanie nowych węzłów do klastra i aktualizacja wersji Cassandry odbywa się w locie, bez dodatkowej ręcznej interwencji i rekonfiguracji innych węzłów.

Jednak wysoce zalecane jest ponowne generowanie kluczy (etykiet) dla każdego węzła, w tym już istniejącego, w celu zachowania jakości równoważenia obciążenia. Generowania klucza dla istniejących węzłów można uniknąć w przypadku wielokrotnego wzrostu liczby węzłów (2 razy, 3 razy itd.).

4.2 Model danych

W terminologii Cassandry aplikacja działa z przestrzenią kluczy, co odpowiada koncepcji schematu bazy danych w modelu relacyjnym. Ta przestrzeń kluczy może zawierać kilka rodzin kolumn, co odpowiada koncepcji tabeli relacyjnej.

Z kolei rodziny kolumn zawierają kolumny (kolumny), które są łączone za pomocą klucza (klucza wiersza) w rekordzie (wierszu). Kolumna składa się z trzech części: nazwa (nazwa kolumny), znacznik czasu (znacznik czasu) i wartość (wartość). Kolumny w rekordzie są uporządkowane. W przeciwieństwie do relacyjnej bazy danych nie ma ograniczeń co do tego, czy rekordy (a w przypadku bazy danych są to wiersze) zawierają kolumny o takich samych nazwach jak w innych rekordach - nie.

Rodziny kolumn mogą być kilku rodzajów, ale w tym artykule pominiemy ten szczegół. Również w najnowszych wersjach Cassandry możliwe stało się wykonywanie zapytań definiujących i zmieniających dane (DDL, DML) z wykorzystaniem języka CQL, a także tworzenie indeksów wtórnych.

Konkretna wartość przechowywana w kasandrze jest identyfikowana przez:

  • keyspace jest powiązaniem z aplikacją (domeną). Umożliwia hostowanie danych z różnych aplikacji w tym samym klastrze;
  • rodzina kolumn jest powiązaniem z zapytaniem;
  • key jest powiązaniem z węzłem klastra. Klucz określa, na których węzłach zostaną zapisane zapisane kolumny;
  • nazwa kolumny jest powiązaniem z atrybutem w rekordzie. Umożliwia przechowywanie wielu wartości w jednym wpisie.

Każda wartość jest powiązana ze znacznikiem czasu, liczbą określoną przez użytkownika, która jest używana do rozwiązywania konfliktów podczas rejestrowania: im większa liczba, tym nowsza kolumna jest brana pod uwagę, a po porównaniu zastępuje stare kolumny.

4.3 Typy danych

Według typów danych: przestrzeń kluczy i rodzina kolumn to łańcuchy znaków (nazwy); znacznik czasu to liczba 64-bitowa; a klucz, nazwa kolumny i wartość kolumny to tablica bajtów. Cassandra ma również pojęcie typów danych. Te typy mogą być określone (opcjonalnie) przez programistę podczas tworzenia rodziny słupów.

Dla nazw kolumn nazywa się to komparatorem, dla wartości i kluczy nazywa się to walidatorem. Pierwsza określa, jakie wartości bajtów są dozwolone dla nazw kolumn i jak je uporządkować. Po drugie, jakie wartości bajtów są prawidłowe dla wartości kolumn i kluczy.

Jeśli te typy danych nie są ustawione, cassandra przechowuje wartości i porównuje je jako ciągi bajtów (BytesType), ponieważ w rzeczywistości są one przechowywane wewnętrznie.

Typy danych to:

  • BytesType : dowolne ciągi bajtów (bez sprawdzania poprawności)
  • AsciiType : Ciąg znaków ASCII
  • UTF8Type : Ciąg UTF-8
  • IntegerType : liczba o dowolnym rozmiarze
  • Int32Type : liczba 4-bajtowa
  • LongType : liczba 8-bajtowa
  • UUIDType : UUID typu 1 lub 4
  • TimeUUIDType : Wpisz 1 identyfikator UUID
  • DateType : 8-bajtowa wartość znacznika czasu
  • BooleanType : dwie wartości: prawda = 1 lub fałsz = 0
  • FloatType : 4-bajtowa liczba zmiennoprzecinkowa
  • DoubleType : 8-bajtowa liczba zmiennoprzecinkowa
  • DecimalType : liczba o dowolnym rozmiarze i zmiennoprzecinkowa
  • CounterColumnType : licznik 8 bajtów

W cassandrze wszystkie operacje zapisu danych są zawsze operacjami przepisywania, to znaczy, jeśli kolumna z tym samym kluczem i nazwą, która już istnieje, trafia do rodziny kolumn, a znacznik czasu jest większy niż ten, który został zapisany, to wartość jest nadpisywana . Zarejestrowane wartości nigdy się nie zmieniają, pojawiają się tylko nowsze kolumny z nowymi wartościami.

Pisanie do Cassandry jest szybsze niż czytanie. Zmienia to podejście przyjęte w projekcie. Jeśli spojrzymy na Cassandrę z punktu widzenia projektowania modelu danych, łatwiej wyobrazić sobie rodzinę kolumn nie jako tabelę, ale jako zmaterializowany widok - strukturę, która reprezentuje dane jakiegoś złożonego zapytania, ale przechowuje je na dysk.

Zamiast próbować komponować dane w jakiś sposób za pomocą zapytań, lepiej spróbować przechowywać wszystko, co może być potrzebne dla tego zapytania w rodzinie docelowej. Oznacza to, że należy podejść nie od strony relacji między podmiotami lub relacji między obiektami, ale od strony zapytań: które pola należy wybrać; w jakiej kolejności powinny iść zapisy; jakie dane związane z głównymi należy zażądać razem - wszystko to powinno już być przechowywane w rodzinie kolumn.

Liczba kolumn w rekordzie jest teoretycznie ograniczona do 2 miliardów. To krótka dygresja, a więcej szczegółów można znaleźć w artykule o technikach projektowania i optymalizacji. A teraz zagłębimy się w proces zapisywania danych w Cassandrze i odczytywania ich.