Zaawansowana obsługa stołu w Cassandra

W poprzednich samouczkach w pełni weszliśmy z CQL i sposób, w jaki pomaga nam to zarządzać Kasandra, widzieliśmy podstawowe operacje dla spacje klawiszy i tabel w Cassandrze, moglibyśmy je zastosować do stworzenia początkowej struktury w Bazie Danych, jednak istnieje wiele zaawansowanych koncepcji, które musimy znać, aby jak najlepiej wykorzystać Cassandrę.
Te koncepcje lub charakterystyka, aby je w jakiś sposób nazwać, pozwalają nam osiągnąć różne funkcjonalności w naszych stołach, dając nam wachlarz możliwości znacznie większy niż pozostałe. Baza danych NoSQL.
Wcześniej stworzyliśmy kilka tabel i używaliśmy wartości takich jak tekst czy data dla naszych kolumn, ale to nie wszystko CQL ma dostępne, zobaczmy, jakie dane mamy dla naszych operacji:
asciiCiąg znaków US-ASCII.
bigint64-bitowa liczba całkowita długa.
kropelkaTyp danych wyrażony w postaci szesnastkowej w konsoli poleceń CQLDodatkowo nie ma walidacji i opiera się na dowolnych bajtach.
logiczneKlasyczny typ danych Boolean, w którym jego wartości mogą być prawdziwe lub fałszywe.
ladacounter to nowy typ danych dla tych z nas, którzy pochodzą ze świata relacyjnego i wskazuje, że jest rozproszony w wersji 64-bitowej.
dziesiętnyInny rodzaj danych, które możemy rozpoznać, co zapewnia nam dokładność dziesiętną naszych informacji.
podwójnieTyp danych zmiennoprzecinkowych, ale oparty na 64 bitach.
PlatformaPodobnie jak poprzedni, jest to typ danych zmiennoprzecinkowych, ale oparty na 32 bitach.
inetaTen typ jest dość szczególny, a jednocześnie bardzo przydatny i pozwala na przechowywanie ciągu znaków adresu IP, obsługuje zarówno format IPV4 Co IPV6.
intKlasyczny typ danych całkowitych, który obsługuje liczby do 32 bitów.
listaKolejny rodzaj danych, który debiutuje w Cassandrze i pozwala na przechowywanie uporządkowanego zbioru elementów.
mapaPodobnie jak lista, jest to kolejny rodzaj nowych danych, który pozwala nam przechowywać tablicę asocjacyjną, co jest bardzo przydatne przy tworzeniu aplikacji.
ustawićPodobnie jak typ danych list, przechowuje kolekcję elementów, ale bez określonej kolejności.
tekstPrzechowuje zakodowany ciąg znaków.
znak czasuTyp danych przechowujący datę i godzinę, zakodowany jako 8-bajtowa liczba całkowita.
odmianaTyp danych Precision dla dowolnych liczb całkowitych.
Jak widać, istnieje wiele rodzajów danych, które możemy rozpoznać, jeśli pochodzimy ze świata relacyjnego, na przykład inne, które zobaczymy po raz pierwszy i które sprawiają, że Kasandra wyróżnia się na tle innych Baz Danych.
w Kasandra mamy nie tylko typy danych dla naszych tabel, dzięki CQL Możemy przypisać do tabel w naszych właściwościach bazy danych, które bardzo nam pomagają w zadaniach związanych z konserwacją i rozwojem, zobaczmy, co mamy dostępne.
BuforowanieTa właściwość daje nam optymalizację pamięci podręcznej. Poziomy dostępne dla tej nieruchomości to tam lub wszyscy, tylko klucze lub tylko klucze, tylko wiersze lub po prostu wiersze i Żaden lub żaden. Wszystkie opcje są jednak całkiem przydatne tylko_wiersz należy używać ostrożnie, ponieważ Kasandra umieścić znaczną ilość danych w pamięci, gdy ta opcja jest używana.
KomentarzOpcja obecna w modelu relacyjnym i używana przez administratorów lub programistów do robienia notatek i wyróżniania ważnych szczegółów w tabelach.
ZagęszczanieTa właściwość pozwala zdefiniować strategię zarządzania Mennica, mogą być następujących typów: Pierwszy Rozmiar warstwowy która jest wyzwalana, gdy tabela przekroczy limit, zaletą tej strategii jest to, że nie obniża ona wydajności zapisu, natomiast wadą jest to, że czasami wykorzystuje dwukrotnie większy rozmiar danych na dysku, co skutkuje słabą wydajnością czytanie. Druga strategia to Wyrównane Zagęszczanie i działa na różnych poziomach w czasie, łącząc tabele z dłuższymi, co daje całkiem dobrą wydajność odczytu.
KompresjaTa właściwość określa sposób kompresji informacji. Możemy wybrać, aby uzyskać korzyści w zakresie prędkości lub przestrzeni, gdzie im wyższa prędkość, tym mniej miejsca na dysku zostaje zaoszczędzone.
Gc_grace_secondsTa właściwość określa czas oczekiwania na usunięcie informacji z nagrobków. Domyślnie jest to 10 dni.
Populate_io_cache_on_flushTa właściwość jest domyślnie wyłączona i powinniśmy ją aktywować tylko wtedy, gdy mamy nadzieję, że wszystkie informacje zmieszczą się w pamięci podręcznej.
Read_repair_chanceBardzo interesująca właściwość, która wskazuje liczbę od 0 do 1,0 określającą prawdopodobieństwo naprawy informacji, gdy kworum nie zostanie osiągnięte. Wartość domyślna to 0,1.
Replikuj_przy_zapisieTa właściwość dotyczy tylko tabel typu lada. Po zdefiniowaniu repliki zapisują dane we wszystkich replikach, których dotyczy problem, ignorując określony poziom spójności.
Tak więc wiemy już, co mamy, zarówno na poziomie typów danych, jak i właściwości, nadszedł czas, aby zastosować niektóre rzeczy nauczone do naszych tabel w Kasandra.
Najpierw stworzymy prostą tabelę, do której zastosujemy właściwość comments, zobaczmy składnię, której do tego użyjemy:

 Artykuły CREATE TABLE (tytuł tekstu, treść tekstu, kategoria tekstu, klucz podstawowy (tytuł)) WITH komentarz = 'Tabela do przechowywania informacji o artykule';

Otwieramy naszą konsolę poleceń CQL i tworzymy naszą tabelę ze wspomnianą właściwością, zobaczmy jak ona wygląda:

Jak już wiemy konsola poleceń nic nie zwraca poza tym, że nie ma błędu, ale jeśli chcemy zobaczyć te zmiany możemy przejść do naszego OpsCenter i sprawdź, czy wszystko poszło poprawnie:

POWIĘKSZAĆ

Jak widać, możemy zobaczyć nasz komentarz i inne właściwości z ich domyślnymi wartościami. Należy wspomnieć, że definicja pozostałych właściwości w: Kasandra jest to dość proste, jak mogliśmy zobaczyć na poprzednim przykładzie, używając składni Z możemy to zrobić bez problemu.
Przeprowadzimy kolejny przykład, w którym zdefiniujemy właściwości kompresja Tak zagęszczanie ale w tym celu ważne jest, aby wiedzieć, że mają szereg opcji podrzędnych do ich użycia, zobaczmy kompresja że powinniśmy wiedzieć:
Stabilna_kompresjaTa opcja określa algorytm kompresji do użycia, jej wartości to: Kompresor LY4, kompresor Snappy, Tak DeflateCompressor.
Chunck_length_kbTabele są kompresowane blokami. Dłuższe wartości na ogół zapewniają lepszą kompresję, ale zwiększają rozmiar odczytywanych informacji. Domyślnie ta opcja jest ustawiona na 64 kb.
Manipulowanie opcjami kompresji może prowadzić do znacznego wzrostu wydajności, w tym wielu implementacji Kasandra Są z tymi wartościami domyślnymi, ale dla perfekcji konieczne jest użycie tych wartości. Zobaczmy teraz, co musimy wiedzieć, aby zagęszczanie:
WłączonyOkreśla, czy właściwość będzie działać w tabeli, chociaż domyślnie wszystkie właściwości mają zagęszczanie włączony.
KlasaTutaj zdefiniujemy rodzaj strategii obsługi tabel.
min_prógTa wartość jest dostępna ze strategią Rozmiar warstwowy y reprezentuje minimalną liczbę tabel potrzebnych do rozpoczęcia procesu zagęszczania. Domyślnie jest zdefiniowany na 4.
max_thresholdDostępne w ten sam sposób w strategii Rozmiar warstwowy y określa maksymalną liczbę tabel przetwarzanych w kompakcie. Domyślnie jest zdefiniowany na 32.
To jedne z najważniejszych opcji dla tych właściwości, należy wspomnieć, że do definicji tych opcji musimy użyć składni JSON Aby być poprawnym, zobaczmy przykład włączenia tych dwóch właściwości:

 CREATE TABLE table_for_properties (identyfikator int, nazwa tekstu, właściwość tekstowa, numer wariantu, klucz podstawowy (id)) WITHcompression = {'sstable_compression': 'DeflateCompressor', 'chunk_length_kb': 64} ANDcompaction = {'class': 'SizeTieredCompactionStrategy', 'próg_min': 6};

Jak widać zmieniliśmy rodzaj kompresji i zdefiniowaliśmy dla niej rozmiar, dodatkowo dla zagęszczanie zostawiliśmy zwykłą strategię z wartością klasa i zdefiniowaliśmy min_próg podobnie jak 6 zwiększył domyślną wartość w ten sposób, na koniec zobaczmy, jak to wygląda, gdy wykonamy to w naszej konsoli poleceń:

W poprzednim samouczku mogliśmy zobaczyć, że w wyniku zdefiniowania więcej niż jednego klucza podstawowego są one tworzone jako klawisze klastrowe i powiedz nam drogę Kasandra sortuje informacje, domyślnie kolejność jest określona w porządku rosnącym i wykonanie zapytania w porządku malejącym może spowodować problemy z wydajnością, jednak Cassandra ma rozwiązanie na każdy problem i jest to ze zdaniem KLASTROWANIE ***** BY. Zobaczmy, jak z niego korzystać.

 CREATE TABLE order_users (tekst użytkownika, data datownik, zmienność wynagrodzenia, tekst działu, tekst kierownika, PRIMARY KEY (użytkownik, data)) WITH CLUSTERING ***** BY (data DESC);

Uruchommy naszą składnię w konsoli poleceń i zobaczmy, jak ona wygląda:

Jak widzieliśmy dość łatwo było rozwiązać ten problem za pomocą prostej linii, ale co ważniejsze, udało nam się poszerzyć naszą wiedzę na temat obsługi stołów w Kasandra, którym kończymy ten samouczek, w którym omówiliśmy wszystko, co musimy wiedzieć do optymalnego tworzenia tabel w Kasandra.