Baza danych Cassandra. Jezyk CQL.
Transkrypt
Baza danych Cassandra. Jezyk CQL.
Baza danych Cassandra. Język CQL. Baza danych Cassandra. Język CQL. Technologie Zarządzania Treścią dr inż. Robert Perliński [email protected] Politechnika Częstochowska Instytut Informatyki Teoretycznej i Stosowanej 14 stycznia 2017 1/82 Plan prezentacji 1 Zapytania - język CQL 2 CQL Definicje Identyfikatory i słowa kluczowe Stałe Typy danych Definiowanie danych 3 Źródła Baza danych Cassandra. Język CQL. 2/82 CQL The Cassandra Query Language (CQL) to główny język komunikacji z bazą Cassandra. Do interakcji z Cassandrą najprościej używać narzędzia cqlsh. Pozwala na tworzenie przestrzeni kluczy, tabel, do których później można dodawać dane i je odczytywać, ... Graficzne narzędzie to DataStax DevCenter - omówione wcześniej. Baza danych Cassandra. Język CQL. 3/82 CQL - części składowe i elementy języka Części składowe języka CQL: Definicja danych (ang. Data Definition) - tworzenie, modyfikowanie i usuwanie wszelkich obiektów w bazie, od przestrzeni kluczy po funkcje czy wyzwalacze. Manipulacja danymi (ang. Data Manipulation - INSERT, UPDATE, DELETE i BATCH. Zapytania (ang. Queries) - SELECT. Zarządzanie rolami (ang. Database Roles) - role i użytkownicy (CREATE ROLE, ALTER ROLE, DROP ROLE, ..., DROP USER, ALTER USER) Nadawanie uprawnień (ang. Data Control - GRANT PERMISSION i REVOKE PERMISSION. Elementy języka CQL: Identyfikatory, stałe, słowa kluczowe. Typy danych - stemple czasowe, daty, czas, liczniki, praca z kolekcjami. Funkcje wbudowane i definiowane przez użytkownika. Agregacje wbudowane i definiowane przez użytkownika. Wsparcie dla formatu JSON. Baza danych Cassandra. Język CQL. 4/82 CQL - proste operacje na bazie danych Proste operacje na bazie danych z użyciem CQL: cqlsh> CREATE KEYSPACE uczelnia WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 }; cqlsh> USE uczelnia; cqlsh:uczelnia> DESC TABLES; <empty> CREATE TABLE IF NOT EXISTS student ( id uuid, imie text, nazwisko text, dataur date, PRIMARY KEY(id) ); CREATE COLUMNFAMILY wykladowca ( id int, imie text, nazwisko text, PRIMARY KEY(id) ); Baza danych Cassandra. Język CQL. 5/82 CQL - proste operacje na bazie danych Proste operacje na bazie danych z użyciem CQL: cqlsh:uczelnia> INSERT INTO student (id,imie,nazwisko,dataur) VALUES (now(), 'Helena', 'Zwyszkiewicz', '1991-12-29'); cqlsh:uczelnia> INSERT INTO student (id,imie,nazwisko,dataur) VALUES (now(), 'Krzysztof', 'Bąk', '1993-01-12'); cqlsh:uczelnia> INSERT INTO wykladowca (id,imie,nazwisko) VALUES (1, 'Witold', 'Koszacki') ; cqlsh:uczelnia> INSERT INTO wykladowca (id,imie,nazwisko) VALUES (2, 'Janina', 'Nowaczek') ; cqlsh:uczelnia> SELECT * FROM student; cqlsh:uczelnia> SELECT * FROM wykladowca; Baza danych Cassandra. Język CQL. 6/82 CQL - proste operacje na bazie danych Proste operacje na bazie danych z użyciem CQL: Baza danych Cassandra. Język CQL. 7/82 Identyfikatory i słowa kluczowe Język CQL używa identyfikatorów albo nazw do identyfikacji tabel, kolumn i innych obiektów. Identyfikator jest tokenem pasujący do wyrażenia: [a-zA-Z][a-zA-Z0-9_]* Część z tych identyfikatorów jak SELECT czy WITH to słowa kluczowe. Mają one określone znaczenie dla CQL i w większości są zarezerwowane. Wielkość liter identyfikatorów i słów kluczowych nie ma znaczenia: SELECT, select, SeLecT albo myid, myId, MYID. Konwencja zakłada pisanie słów kluczowych dużymi literami, a innych identyfikatorów małymi. ”Cytowane” identyfikatory - dowolny ciąg znaków zamknięty z cudzysłowach. nigdy nie są słowami kluczowymi, np . "select" może być nazwą kolumny, ale select już nie, wielkość liter w ”cytowanych” identyfikatorach ma znaczenie: "Moje ID" ! = "moje id" ale "mojeid" == mojeid == mojeID Baza danych Cassandra. Język CQL. 8/82 Identyfikatory i słowa kluczowe Identyfikatory w cydzysłowach i bez nich bardziej formalnie: identifier ::= unquoted_identifier ::= quoted_identifier ::= Baza danych Cassandra. Język CQL. unquoted_identifier | quoted_identifier re('[a-zA-Z][a-zA-Z0-9_]*') '"' (any character where " can appear if doubled)+ '"' 9/82 Identyfikatory i słowa kluczowe Słowa zarezerwowane nie mogą być używane jako identyfikatory. Słowa niezarezerwowane mają znaczenie tylko w pewnym kontekście - poza tym mogą być identyfikatorami. Keyword Reserved? ------------------ADD yes AGGREGATE no ALL no ALLOW yes ALTER yes AND yes APPLY yes AS no ASC yes ASCII no AUTHORIZE yes BATCH yes BEGIN yes BIGINT no BLOB no BOOLEAN no BY yes CALLED no CLUSTERING no COLUMNFAMILY yes COMPACT no CONTAINS no COUNT no COUNTER no CREATE yes Keyword Reserved? ----------------CUSTOM no DATE no DECIMAL no DELETE yes DESC yes DESCRIBE yes DISTINCT no DOUBLE no DROP yes ENTRIES yes EXECUTE yes EXISTS no FILTERING no FINALFUNC no FLOAT no FROM yes FROZEN no FULL yes FUNCTION no FUNCTIONS no GRANT yes IF yes IN yes INDEX yes INET no Baza danych Cassandra. Język CQL. Keyword Reserved? --------------------INFINITY yes INITCOND no INPUT no INSERT yes INT no INTO yes JSON no KEY no KEYS no KEYSPACE yes KEYSPACES no LANGUAGE no LIMIT yes LIST no LOGIN no MAP no MODIFY yes NAN yes NOLOGIN no NORECURSIVE yes NOSUPERUSER no NOT yes NULL yes OF yes ON yes Keyword Reserved? --------------------OPTIONS no OR yes ORDER yes PASSWORD no PERMISSION no PERMISSIONS no PRIMARY yes RENAME yes REPLACE yes RETURNS no REVOKE yes ROLE no ROLES no SCHEMA yes SELECT yes SET yes SFUNC no SMALLINT no STATIC no STORAGE no STYPE no SUPERUSER no TABLE yes TEXT no TIME no Keyword Reserved? ------------------TIMESTAMP no TIMEUUID no TINYINT no TO yes TOKEN yes TRIGGER no TRUNCATE yes TTL no TUPLE no TYPE no UNLOGGED yes UPDATE yes USE yes USER no USERS no USING yes UUID no VALUES no VARCHAR no VARINT no WHERE yes WITH yes WRITETIME no 10/82 Stałe w języku CQL Język CQL ma następujące stałe: constant ::= string ::= integer float boolean uuid hex blob ::= ::= ::= ::= ::= ::= string | integer | float | boolean | uuid | blob | NULL '\'' (dowolny znak gdzie ' może się pojawić jako podwojony)+ '\'' '$$' (dowolny znak inny niż '$$') '$$' re('-?[0-9]+') re('-?[0-9]+(\.[0-9]*)?([eE][+-]?[0-9+])?') | NAN | INFINITY TRUE | FALSE hex{8}-hex{4}-hex{4}-hex{4}-hex{12} re("[0-9a-fA-F]") '0' ('x' | 'X') hex+ Napisy (string) są dowolnym ciągiem znaków zamkniętych w ’ albo $$ ’It’’s raining today’ $$It’s raining today$$ Typy: integer, float i boolean są wprowadzane standardowo, float dodatkowo ma NAN i INFINITY. CQL wspiera stałe UUID (Universally unique identifier). Pole BLOB zawiera wartość w formie zapisu hexadecymalnego poprzedzonego 0x NULL oznacza brak wartości. Baza danych Cassandra. Język CQL. 11/82 Nazwy (ang. terms) Term w języku CQL jest: stałą, literałem kolekcji, typu zdefiniowanego przez użytkownika albo krotki, wywołaniem funkcji, wskazówką (ang. hint), znacznikiem (oznaczeniem) związania, określa, że zmienna będzie z nim związana w czaie wykonywania, może być anonimowy (?) albo nazwany :jakas_nazwa. term literal function_call type_hint bind_marker ::= ::= ::= ::= ::= constant | literal | function_call | type_hint | bind_marker collection_literal | udt_literal | tuple_literal identifier '(' [ term (',' term)* ] ')' '(' cql_type ')' term '?' | ':' identifier Baza danych Cassandra. Język CQL. 12/82 Komentarze Komentarze w języku CQL: jednoliniowe zaczynają się -- albo //, wieloliniowe zaczynają się /* i kończą się */, nie jest wspierane zagnieżdżanie. -- Pierwszy komentarz // Drugi komentarz, też fajny :) /* Trzeci komentarz, najlepszy, bo w wielu linijkach :D */ Baza danych Cassandra. Język CQL. 13/82 Instrukcje Instrukcje w języku CQL można podzielić na kategorie: definicja danych (ang. Data Definition statements) - definiowanie i zmiana sposobu przechowywania danch (przestrzenie kluczy i tabele), manipulacja danymi (ang. Data Manipulation statements) - pobieranie, wstawianie i usuwanie danych, tworznie indeksów (ang. Secondary Indexes statements), tworznie perspektyw (ang. Materialized Views statements), przydział ról (ang. Database Roles statements), przydział uprawnień (ang. Permissions statements), funkcje użytkownika (ang. User-Defined Functions statements), typy danych użytkownika (ang. User-Defined Types statements), wyzwalacze (ang. Triggers statements). Instrukcje przygotowane - uruchamiane z parametrami wprowadzanymi przez zmienne związane. Są raz parsowane i uruchamiane wiele razy z różnymi wartościami parametrów. Baza danych Cassandra. Język CQL. 14/82 Instrukcje - lista z podziałem I cql_statement statement ::= ::= statement [ ';' ] ddl_statement | dml_statement | secondary_index_statement | materialized_view_statement | role_or_permission_statement | udf_statement | udt_statement | trigger_statement ddl_statement ::= use_statement | create_keyspace_statement | alter_keyspace_statement | drop_keyspace_statement | create_table_statement | alter_table_statement | drop_table_statement | truncate_statement Baza danych Cassandra. Język CQL. 15/82 Instrukcje - lista z podziałem II dml_statement ::= select_statement | insert_statement | update_statement | delete_statement | batch_statement secondary_index_statement ::= create_index_statement | drop_index_statement materialized_view_statement ::= create_materialized_view_statement | drop_materialized_view_statement udf_statement ::= create_function_statement | drop_function_statement | create_aggregate_statement | drop_aggregate_statement Baza danych Cassandra. Język CQL. 16/82 Instrukcje - lista z podziałem III role_or_permission_statement ::= create_role_statement | alter_role_statement | drop_role_statement | grant_role_statement | revoke_role_statement | list_roles_statement | grant_permission_statement | revoke_permission_statement | list_permissions_statement | create_user_statement | alter_user_statement | drop_user_statement | list_users_statement udt_statement ::= create_type_statement | alter_type_statement | drop_type_statement trigger_statement ::= create_trigger_statement | drop_trigger_statement Baza danych Cassandra. Język CQL. 17/82 Typy danych w CQL CQL: jest językiem typowanym, wspiera bogaty zbiór typów danych, zawiera: cql_type ::= native_type | collection_type | user_defined_type | tuple_type | custom_type Baza danych Cassandra. Język CQL. 18/82 Proste typy danych Proste typy danych w CQL: native_type ::= ASCII | BIGINT | BLOB | BOOLEAN | COUNTER | DATE | DECIMAL | DOUBLE | FLOAT | INET | INT | SMALLINT | TEXT | TIME | TIMESTAMP | TIMEUUID | TINYINT | UUID | VARCHAR | VARINT Baza danych Cassandra. Język CQL. 19/82 Proste typy danych dostępne w CQL Typ ASCII BIGINT BLOB BOOLEAN COUNTER DATE DECIMAL DOUBLE FLOAT INET INT SMALLINT TEXT TIME TIMESTAMP TIMEUUID Wspierane stałe string integer blob boolean integer integer, string integer, float integer, float integer, float string integer integer string integer, string integer, string uuid TINYINT UUID VARCHAR VARINT integer uuid string integer Baza danych Cassandra. Język CQL. Opis zbiór znaków ASCII 64-bitowa liczba ze znakiem dowolny zbiór bajtów wartość true albo false licznik kolumn data bez informacji o czasie (godzina itd.) liczba dziesiętna różnej precyzji 64-bitowa liczba zmiennopozycyjna (IEEE-754) 32-bitowa liczba zmiennopozycyjna (IEEE-754) adres IP, 4-bajtowy (IPv4) albo 16-bajtowy (IPv6) 32-bitowa liczba całkowita ze znakiem 16-bitowa liczba całkowita ze znakiem zbiór znaków (string) zakodowany w UTF8 czas (bez wartości daty), precyzja do nanosekund punkt czasowy (data i czas), precyzja do milisekund pierwsza wersja UUID, zwykle używana jako „bezkonfliktowy” punkt czasowy 8-bitowa liczba ze znakiem UUID dowolnej wersji zbiór znaków (string) zakodowany w UTF8 liczba całkowita dowolnej precyzji 20/82 Liczniki Liczniki (ang. counters): używany do definiowania kolum licznikowych, kolumna licznikowa to kolumna, której wartość to 64-bitowa liczba całkowita ze znakiem, dostępne są na niej dwie operacji: zmniejszanie i zwiększanie, wartości licznika nie można ustawić, przed pierwszą inkrementacją/dekrementacją licznik nie istnieje, pierwsza inkrementacja/dekrementacja zmienia wartość tak, jakby wcześniej wynosiła ona 0. Ograniczenia liczników: nie mogą być używane na kolumnach będących częścia klucza głównego (PRIMARY KEY), tabela albo posiada tylko liczniki albo nie posiada ich wcale, dla liczników nie można nałożyć ograniczenia czasu ich istnienia, można usuwać liczniki ale gwarantowane działanie jest tylko za pierwszym razem, później nie ma gwarancji właściwego działania, modyfikacja liczników z natury nie jest idempotentna (zmiany za każdym razem). Baza danych Cassandra. Język CQL. 21/82 Praca z punktami czasowymi Punkty czasowe: są reprezentowane przez 64-bitowe liczby całkowite ze znakiem, wartość odpowiada liczbie milisekund od początku epoki UNIX’a (1 stycznia 1970) wprowadzanie danych punktu czasowego (jako integer albo string (ISO 8601)): 1112477832000 '1970-01-01T00:00:07+0000' '2005-04-02 21:37+0000' '2005-04-02T21:37:12+0000' '2005-04-02T21:37:12.000+0000' '2005-04-02+0000' // 7 sekund czyli wartość 7000 // 4-cyfrowe oznacznie strefy czasowej // wersja z milisekundami // z pominięciem czasu SELECT blobasbigint(timestampAsBlob('2005-04-02+0000')) as "data" FROM wykladowca; // 1112477832000 SELECT toUnixTimestamp((timestamp)'2005-04-02T21:37:12+0000') as "data" FROM wykladowca; // 1112477832000 SELECT toTimestamp('2005-04-02') as "data" FROM wykladowca; // 2005-04-02 00:00:00.000000+0000 Baza danych Cassandra. Język CQL. 22/82 Praca datą i czasem Daty: kodowane jako 32-bitowe liczby czałkowite bez znaku, reprezentują liczbę dni od początku epoki UNIX’a, środek daty ma wartość 231 , można wprowadzać jako integer albo string (format yyyy-mm-dd), Czas: kodowany jako 64-bitowa liczba całkowita ze znakiem, reprezentuje liczbę nanosekund od północy, można wprowadzać jako integer albo string (format hh:mm:ss[.fffffffff]), prawidłowe czasy: '21:37:12' '21:37:12.123' '21:37:12.123456' '21:37:12.123456789' Baza danych Cassandra. Język CQL. 23/82 Kolekcje w CQL CQL wspiera trzy rodzaje kolekcji: mapy, zbiory i listy. collection_type ::= MAP '<' cql_type ',' cql_type '>' | SET '<' cql_type '>' | LIST '<' cql_type '>' Wprowadzanie do nich wartości: collection_literal map_literal set_literal list_literal ::= ::= ::= ::= map_literal | set_literal | list_literal '{' [ term ':' term (',' term : term)* ] '}' '{' [ term (',' term)* ] '}' '[' [ term (',' term)* ] ']' Jako literały w kolekcji nie może się pojawić wartość NULL ani zmienna związana. Baza danych Cassandra. Język CQL. 24/82 Kolekcje w CQL - ważna charakterystyka Kolekcji używamy do przechowywania małych zbiorów danych, np. telefony czy maile jednej osoby. Dla zawartości, które mogą się w nieskończoność rozrastać, np. lista komentarzy użytkowników, kolekcje nie są dobrym rozwiązaniem; używamy wtedy specjalnej tabeli z kolumnami z grupowaniem. Jest niedobrym zwyczajem używać kolekcji (pojedynczej) do przechowywania duży ilości danych. Baza danych Cassandra. Język CQL. 25/82 Mapy Mapa to posortowany zbiór par klucz-wartość. Klucze są unikalne. Mapa jest posortowana po kluczach. map_literal ::= '{' [ term ':' term (',' term : term)* ] '}' CREATE TABLE prac_zoo ( id int PRIMARY KEY, nazwa text, zwierzaki map<text, text> // Mapa nazw zwierzaków i ich gatunku ); INSERT INTO prac_zoo (id, nazwa, zwierzaki) VALUES (1, 'Marysia Mrugalska', { 'Kajtek' : 'pies jamnik', 'Puszek' : 'kot perski' } ); Baza danych Cassandra. Język CQL. 26/82 Mapy Operacje wykonywane na mapach: // zastąpienie zawartości całej mapy UPDATE prac_zoo SET zwierzaki = { 'Wojtek' : 'słoń' } WHERE id = 1; // aktualizacja jednego pola UPDATE prac_zoo SET zwierzaki['Wojtek'] = 'hipopotam' WHERE id = 1; // dodanie jednego pola UPDATE prac_zoo SET zwierzaki['Ares'] = 'koń, arab' WHERE id = 1; // dodanie wielu pól na raz UPDATE prac_zoo SET zwierzaki = zwierzaki + { 'Amelia' : 'żyrafa', 'Herman' : 'antylopa gnu' } WHERE id = 1; // usunięcie pola DELETE zwierzaki['Ares'] FROM prac_zoo WHERE id = 1; // usunięcie pola albo pól UPDATE prac_zoo SET zwierzaki = zwierzaki - { 'Herman', 'Amelia'} WHERE id = 1; // dodanie/aktualizacja pary klucz-wartość z ograniczeniem czasowym na 10 s UPDATE prac_zoo USING TTL 10 SET zwierzaki['Miśka'] = 'foka' WHERE id = 1; Baza danych Cassandra. Język CQL. 27/82 Zbiory Zbiór jest posortowaną kolekcją unikalnych wartości. set_literal ::= '{' [ term (',' term)* ] '}' CREATE TABLE obrazy ( nazwa text PRIMARY KEY, wlasciciel text, tagi set<text> // Zbiór wartości tekstowych ); INSERT INTO obrazy (nazwa, wlasciciel, tagi) VALUES ('kasprowy.jpg', 'jkowalski', { 'Tatry', 'schronisko' }); // zmiana całego zbioru UPDATE obrazy SET tagi = {'zima','szczyt','góry'} WHERE nazwa = 'kasprowy.jpg'; // dodanie jednego lub wielu elementów UPDATE obrazy SET tagi = tagi + {'akcja','TOPR'} WHERE nazwa = 'kasprowy.jpg'; // usunięcie jednego lub wielu elementów UPDATE obrazy SET tagi = tagi - { 'zima' } WHERE nazwa = 'kasprowy.jpg'; Tak samo jak w mapach można dodawać elementy na określony czas (TTL). Baza danych Cassandra. Język CQL. 28/82 Listy Lista jest posortowaną kolekcją nieunikalnych wartości. Elementy są uporządkowane położeniem na liście. Mają pewne ograniczenia, które należy uwzględnić zamin się z nich skorzysta. Jeśli się da należy wybierać zbiory (set). Tak samo jak w pozostałych kolekcjach, można dodawać elementy na określony czas (TTL). list_literal ::= '[' [ term (',' term)* ] ']' CREATE TABLE gry ( id text PRIMARY KEY, gra text, lgraczy int, punkty list<int> // Lista liczb całkowitych ); INSERT INTO gry (id, gra, lgraczy, punkty) VALUES ('kolonie2008', 'DixIt', 3, [32, 18, 21]); Baza danych Cassandra. Język CQL. 29/82 Listy // Zmiana całej listy UPDATE gry SET punkty = [30, 31, 22] WHERE id = 'kolonie2008'; // Dodanie elementu na końcu listy UPDATE gry SET lgraczy = 5, punkty = punkty + [ 14, 25 ] WHERE id = 'kolonie2008'; // Dodanie elementu na początku listy UPDATE gry SET lgraczy = 6, punkty = [ 42 ] + punkty WHERE id = 'kolonie2008'; // Zmiana drugiego elementu listy UPDATE gry SET punkty[1] = 17 WHERE id = 'kolonie2008'; // Usuwa drugi element z listy, element musi istnieć inaczej zgłasza błąd, // zmieni indeksy następnych elementów po usuniętym, DELETE punkty[1] FROM gry WHERE id = 'kolonie2008'; // Usuwa wszystkie wystąpienia podanych elementów UPDATE gry SET punkty = punkty - [ 14, 21 ] WHERE id = 'kolonie2008'; Baza danych Cassandra. Język CQL. 30/82 Typy zdefiniowane przez użytkownika Typy zdefiniowane przez użytkownika (ang. user defined types - UDT): można je tworzyć, modyfikować i usuwać, po utworzeniu typu można się do niego odwoływać po nazwie. Tworzenie typu użytkownika (CREATE TYPE): udt_name ::= [ keyspace_name '.' ] identifier create_type_statement ::= field_definition ::= CREATE TYPE [ IF NOT EXISTS ] udt_name '(' field_definition ( ',' field_definition )* ')' identifier cql_type Typ użytkownika: posiada nazwę, której używamy do deklarowania typu kolumn, jest zbiorem pól z określonymi nazwami i typami, włącznie z kolekcjami albo innymi typami użytkownika. Baza danych Cassandra. Język CQL. 31/82 Tworzenie własnych typów I Przykład typów użytkownika CREATE TYPE telefon ( kod_kraju int, numer text, ); Domyślnie tworzony w bieżącej przestrzeni kluczy, przynależy i jest dostępny tylko w niej. Można stworzyć go w innej przestrzeni kluczy (prefiks przed nazwą). Baza danych Cassandra. Język CQL. 32/82 Tworzenie własnych typów II Przykład typów użytkownika CREATE TYPE adres ( ulica text, miasto text, kod text, nr_tel map<text, frozen<telefon>> ); CREATE TABLE osoba ( nazwa text PRIMARY KEY, adresy map<text, frozen<adres>> ); Od wersji 4.0 typy użytkownika w większości przypadków muszą być frozen. Pola typu frozen serializują wiele pól w jedną wartość, nie można aktualizować poszczególnych wartości wewnątrz. Wartość typu frozen jest traktowana jako blob - wymagana jest zmiana całej wartości. Baza danych Cassandra. Język CQL. 33/82 Literały na bazie własnych typów Mając zdefiniowany typ można go użyć podając jego literał: udt_literal ::= '{' identifier ':' term ( ',' identifier ':' term )* '}' INSERT INTO osoba (nazwa, adresy) VALUES ('Zygmunt Marciniak', { 'dom' : { ulica: 'Stacyjna 13/5', miasto: 'Częstochowa', kod: '42-200', nr_tel: { 'komórka' : { kod_kraju: 58, numer: '665 032 413' }, 'stacjonarny' : { kod_kraju: 58, numer: '34 327 61 73' } } }, 'praca' : { ulica: 'Dąbrowskiego 32/8', miasto: 'Częstochowa', kod: '42-217', nr_tel: { 'fax' : { kod_kraju: 58, numer: '34 318 56 92' } } } }); Literał może zawierać tylko pola określone w typie. Niektóre z pól można pominąć - pola te będą miały wartość null. Baza danych Cassandra. Język CQL. 34/82 Modyfikacja własnych typów Istniejący typ można zmodyfikować (ALTER TYPE): alter_type_statement ::= ALTER TYPE udt_name alter_type_modification alter_type_modification ::= ALTER identifier TYPE cql_type | ADD field_definition | RENAME identifier TO identifier ( identifier TO identifier )* Można: modyfikować typ poszczególnych elementów, dodawać nowe pola do typu, nowe pola będą miały wartość null we wszystkich wartościach tego typu wcześniej utworzonych, zmienić nazwę pól danego typu. ALTER TYPE adres ALTER kod TYPE bigint; ALTER TYPE adres ADD kraj text; ALTER TYPE adres RENAME kod TO kod_pocztowy; Baza danych Cassandra. Język CQL. 35/82 Usuwanie własnych typów Istniejący typ można usunąć (DROP TYPE): drop_type_statement ::= DROP TYPE [ IF EXISTS ] udt_name DROP TYPE powoduje natychmiastowe, nieodwracalne usunięcie typu. Próba usunięcia typu, który jest używany przez inny typ, tabelę czy funkcję skończy się błędem. Próba usunięcia typu, który nie istnieje spowoduje błąd chyba, że użyto IF EXISTS, wtedy błędu nie będzie. Baza danych Cassandra. Język CQL. 36/82 Krotki CQL wspiera krotki i typy krotkowe (elementy mogą być różnych typów). Inaczej niż wbudowane typy (kolekcje i typy użytkownika) krotka jest zawsze frozen. Aktualizuje się cała albo wcale. Liczba pól krotki w literale musi się zgadzać z definicją typu, niektóre mogą być pominięte wtedy pola mają wartość null. Typ krotkowy i literały krotkowe definiujemy następująco: tuple_type ::= tuple_literal ::= TUPLE '<' cql_type ( ',' cql_type )* '>' '(' term ( ',' term )* ')' CREATE TABLE meble ( id int PRIMARY KEY, dane tuple<text, text, float, date>, ); INSERT INTO meble (id, dane) VALUES (343, ('Regał Maluch', 'Wspaniały regał...', 3299.99, '2016-12-07') ); Baza danych Cassandra. Język CQL. 37/82 Dowolne typy Dowolne typy (ang. custom types): istnieją głównie ze względu na wsteczną kompatybilność, ich używanie jest niezalecane, dodatkowo: jest trudne, skomplikowane i nie przyjazdne dla użytkownika, inne dostarczone typy, szczególnie definiowane przez użytkownika, powinny wystarczyć w każdym przypadku. custom_type ::= string Baza danych Cassandra. Język CQL. 38/82 Definiowanie danych CQL przechowuje dane w tabelach. Schematy definiują układ danych w tabeli. Tabele są pogrupowane w przestrzenie kluczy. Przestrzeń kluczy definiuje wiele opcji, które określają tabele w niej się znajdujące. Najważniejszym parametrem jest strategia replikacji (SimpleStrategy albo NetworkTopologyStrategy). Zaleca się używanie jednej przestrzeni kluczy na aplikację - wiele klastrów może definiować tylko jedną przestrzeń kluczy. Baza danych Cassandra. Język CQL. 39/82 Proste definicje Nazwy przestrzeni kluczy i tabel określa poniższa gramatyka: keyspace_name table_name name unquoted_name quoted_name ::= ::= ::= ::= ::= name [ keyspace_name '.' ] name unquoted_name | quoted_name re('[a-zA-Z_0-9]{1, 48}') '"' unquoted_name '"' Nazwy przestrzeni kluczy i tabel powinny zawierać tylko znaki alfanumeryczne. Nie mogą być puste ani dłuższe niż 48 znaków. Domyślnie wielkość liter nie ma znaczenia ale wykorzystanie cudzysłowu wymusza rozróżnianie wielkości znaków. Można również zdefiniować opcje instrukcji: options ::= option ::= option ( AND option )* identifier '=' ( identifier | constant | map_literal ) Baza danych Cassandra. Język CQL. 40/82 CREATE KEYSPACE Przestrzeń kluczy tworzymy poleceniem CREATE KEYSPACE: create_keyspace_statement ::= CREATE KEYSPACE [ IF NOT EXISTS ] keyspace_name WITH options CREATE KEYSPACE Uczelnia WITH replication = { 'class': 'SimpleStrategy', 'replication_factor' : 3 }; CREATE KEYSPACE Aquapark WITH replication = { 'class': 'NetworkTopologyStrategy', 'DC1' : 1, 'DC2' : 3 } AND durable_writes = false; Dopuszczalne opcje: replication - obowiązkowa, bez wartości domyślnej - typu mapy - określa strategię replikacji i opcje używane w tej przestrzeni kluczy, durable_writes - nieobowiązkowa, domyślnie true, typu prostego określa czy ma być włączony trwały zapis w postaci logów zatwierdzeń. Baza danych Cassandra. Język CQL. 41/82 CREATE KEYSPACE Właściwość replication jest obowiązkowa i musi posiadać przynajmniej pole class określające strategię replikacji. SimpleStrategy - określa strategię replikacji dla całego klastra. Dostępna opcja replication_factor określa współczynnik replikacji, też jest to opcja obowiązkowa. NetworkTopologyStrategy - pozwala ustawić strategię replikacji osobno dla każdego serwera (centra danych). Pozostałe parametry to są pary klucz-wartość określające nazwę centra danych i współczynnik replikacji. Utworznie przestrzeni kluczy, która już istnieje powoduje błąd jeśli nie użyjemy IF NOT EXISTS. Baza danych Cassandra. Język CQL. 42/82 USE Polecenie USE pozwala zmienić bieżącą przestrzeń kluczy na inną (w ramach połączenia, na którym jest wykonywane polecenie). Bieżąca przestrzeń jest domyślna dla wszystkich tworzonych czy modyfikowanych obiektów (tabele, funkcje, typy użytkownika, ...). use_statement ::= Baza danych Cassandra. Język CQL. USE keyspace_name 43/82 ALTER KEYSPACE ALTER KEYSPACE pozwala zmienić opcje wybranej przestrzeni kluczy. Opcje są takie same jak przy tworzeniu przestrzeni kluczy. alter_keyspace_statement ::= ALTER KEYSPACE keyspace_name WITH options ALTER KEYSPACE Uczelnia WITH replication = { 'class': 'SimpleStrategy', 'replication_factor' : 4 }; Baza danych Cassandra. Język CQL. 44/82 DROP KEYSPACE DROP KEYSPACE pozwala usunąć przestrzeń kluczy o podanej nazwie. Usunięcie przestrzeni kluczy skutkuje natychmiastowym i nieodwracalnym usunięciem samej przestrzeni nazw wraz z ze wszsystkimi obiektami i zawartymi w nich danymi. Zwraca błąd jeśli przestrzeń o podanej nazwie nie istnieje, chyba że podano IF EXISTS. drop_keyspace_statement ::= DROP KEYSPACE [ IF EXISTS ] keyspace_name DROP KEYSPACE Aquapark; Baza danych Cassandra. Język CQL. 45/82 CREATE TABLE Polecenie CREATE TABLE tworzy nową tabelę: create_table_statement::= CREATE TABLE [ IF NOT EXISTS ] table_name '(' column_definition ( ',' column_definition )* [ ',' PRIMARY KEY '(' primary_key ')' ] ')' [ WITH table_options ] column_definition ::= column_name cql_type [ STATIC ] [ PRIMARY KEY] primary_key ::= partition_key [ ',' clustering_columns ] partition_key ::= column_name | '(' column_name ( ',' column_name )* ')' clustering_columns ::= column_name ( ',' column_name )* table_options ::= COMPACT STORAGE [ AND table_options ] | CLUSTERING ORDER BY '(' clustering_order ')' [ AND table_options ] | options clustering_order ::= column_name (ASC | DESC) ( ',' column_name (ASC | DESC) )* Baza danych Cassandra. Język CQL. 46/82 CREATE TABLE - przykłady I Przykłady CREATE TABLE: CREATE TABLE monkeySpecies ( species text PRIMARY KEY, common_name text, population varint, average_size int ) WITH comment='Important biological records' AND read_repair_chance = 1.0; CREATE TABLE timeline ( userid uuid, posted_month int, posted_time uuid, body text, posted_by text, PRIMARY KEY (userid, posted_month, posted_time) ) WITH compaction = { 'class' : 'LeveledCompactionStrategy' }; Baza danych Cassandra. Język CQL. 47/82 CREATE TABLE - przykłady II Przykłady CREATE TABLE: CREATE TABLE loads ( machine inet, cpu int, mtime timeuuid, load float, PRIMARY KEY ((machine, cpu), mtime) ) WITH CLUSTERING ORDER BY (mtime DESC); Tabela w języku CQL ma swoją nazwę i składa się ze zbioru wierszy. Utworznie tabeli określa: z jakich kolumn będą składać się wiersze, które z kolumn utworzą klucz główny, dodatkowe opcje określone dla tabeli. Baza danych Cassandra. Język CQL. 48/82 CREATE TABLE - definiowanie kolumn Każdy wiersz w tabeli ma zbiór predefiniowanych kolumn określonych w czasie tworzenia tabeli (albo przy jej zmianie poleceniem ALTER). Definicja kolumny to zwykle jej nazwa i następujący po niej typ ograniczający wartości, które mogą się w niej znajdować. Definicja kolumny może mieć dwa dodatkowe modyfikatory: STATIC - określa kolumnę jako statyczną, PRIMARY KEY - deklaruje kolumnę jako wyłączny składnik klucza podstawowego tabeli. Baza danych Cassandra. Język CQL. 49/82 CREATE TABLE - kolumny statyczne CREATE TABLE t ( pk int, t int, v text, s text static, PRIMARY KEY (pk, t) ); INSERT INTO t (pk, t, v, s) VALUES (0, 0, 'val0', 'static0'); INSERT INTO t (pk, t, v, s) VALUES (0, 1, 'val1', 'static1'); SELECT * FROM t; pk | t | v | s ----+---+--------+----------0 | 0 | 'val0' | 'static1' 0 | 1 | 'val1' | 'static1' Statyczna kolumna jest dzielona pomiędzy wszystkie wiersze należące do tej samej partycji. Statyczna może być kolumna nie będąca PRIMARY KEY. s ma tą samą wartość (static1) dla obu wierszy w tej samej partycji (pk=0). Drugie wstawianie nadpisało pierwsze. Baza danych Cassandra. Język CQL. 50/82 CREATE TABLE - klucz główny W ramach tabeli wiersz jest jednoznacznie identyfikowany przez klucz główny (PRIMARY KEY). Każda tabela musi mieć jeden klucz główny. Klucz główny składa się z jednej lub więcej kolumn danej tabeli. Syntaktycznie klucz główny określa się wymieniając kolumny po przecinku wewnątrz nawiasu PRIMARY KEY(col1, col2, ...) Kolejność kolumn w definicja klucza głównego ma znacznie. Jeśli klucz główy jest tylko na bazie jednej kolumny to można to zapisać zaraz po opisie kolumny. Baza danych Cassandra. Język CQL. 51/82 CREATE TABLE - klucz główny Definicja klucza głównego w CQL składa się z dwóch cześci: klucz partycjonowania - pierwsza część definicji klucza głównego. Może być pojedynczą kolumną albo grupą kolumn ale potrzebne są dodatkowe nawiasy. Tabela ma zawsze przynajmniej klucz partycjonowania. Przypadek minimalny: CREATE TABLE t (k text PRIMARY KEY); kolumny grupujące - kolumny występujące w kluczu głównym po pierwszym elemencie. Ich kolejność określa porządek grupowania (ang. clustering order ). Przykłady: // a jest kluczem głównym, nie ma kolumn grupujących PRIMARY KEY (a) // a jest kluczem głównym, b i c są kolumnami grupującymi PRIMARY KEY (a, b, c) // a i b tworzą klucz główny (złożony klucz główny), c jest kolumną grupującą PRIMARY KEY ((a, b), c) Baza danych Cassandra. Język CQL. 52/82 CREATE TABLE - klucz partycjonowania W ramach tabeli CQL definiuje takie pojącie jak partycja. Partycja jest zbiorem wierszy, które dzielą tę samą wartość ich klucza partycjonowania. Jeśli klucz partycjonowania ma więcej niż jedną kolumnę, to wartości we wszystkich tych kolumnach muszą być takie same. Przykład: CREATE TABLE t ( a int, b int, c int, d int, PRIMARY KEY ((a, b), c, d) ); SELECT * FROM t; a | b | c | d ---+---+---+--0 | 0 | 0 | 0 0 | 0 | 1 | 1 0 | 1 | 2 | 2 0 | 1 | 3 | 3 1 | 1 | 4 | 4 // // // // // Baza danych Cassandra. Język CQL. row row row row row 1 2 3 4 5 - partycja partycja partycja partycja partycja A A B B C 53/82 CREATE TABLE - klucz partycjonowania Tabela zawsze ma klucz partycjonowania. Jeśli nie ma kolumn grupujących, to każda partycja zawiera tylko jeden wiersz. Najważniejsza własność partycji: wszystkie wiersze należące do tej samej partycji przy replikacji będą składowane na tym samym zbiorze węzłów. klucz partycjonowania określa, w ramach całego klastra, które wiersze będą składowane razem. Ważne jest mądre określenie typu partycjonowania, tak, żeby wiersze, które mają być pobierane razem były w tej samej partycji (polecenia wymagają wtedy przepytania minimalnej liczby węzłów). Z drugiej strony, partycja, która grupuje za dużo danych, może stać się wąskim gardłem, punktem zapalnym. Wszystkie zapisy danych wykonywane na partycji są atomowe i izolowane. Nie jest tak poza obrębem partycji. Właściwy wybór klucza partycjonowania i kolumn grupujących dla tabeli jest jedną z najwazniejszych spraw w Cassandrze. Ma olbrzymi wpływ na to, które zapytania można przeprowadzić i jak będą one efektywne. Baza danych Cassandra. Język CQL. 54/82 CREATE TABLE - kolumny grupujące Kolumny grupujące tabeli definiują porządek grupowania dla danej partycji. Dla danej partycji, wszystkie wiersze są fizycznie uporządkowane w Cassandrze po kolejności grupowania. Przykład: CREATE TABLE t ( a int, b int, c int, PRIMARY KEY (a, b, c) ); INSERT INTO t (a , b , c ) INSERT INTO t (a , b , c ) INSERT INTO t (a , b , c ) INSERT INTO t (a , b , c ) VALUES VALUES VALUES VALUES ( ( ( ( 0, 0, 0, 0, 2, 0, 3, 1, 2); 4); 3); 9); SELECT * FROM t; a | b | c ---+---+--0 | 0 | 4 // row 1 0 | 1 | 9 // row 2 0 | 2 | 2 // row 3 0 | 3 | 3 // row 4 Wiersze są uporządkowane według wartości kolumny b. Baza danych Cassandra. Język CQL. 55/82 CREATE TABLE - kolumny grupujące Jeśli klucz partycjonowania pozwala na grupowanie, to kolumny grupujące kontrolują jak wiersze są przechowywane na serwerach. Pozwala to na bardzo efektywne pobieranie zakresu danych z jednej partycji: SELECT * FROM t WHERE a=0 AND b>0 AND b<=2; a | b | c ---+---+--0 | 1 | 9 0 | 2 | 2 // row 2 // row 3 Baza danych Cassandra. Język CQL. 56/82 CREATE TABLE - opcje Podczas tworzenia tabel w CQL można ustalić wiele opcji. Większość z tych opcji można zmienić po utworzeniu tabel (ALTER TABLE). Opcje określamy po słowie kluczowym WITH. Dwie opcje mające wpływ na zapytania możliwe do wykonania na tabeli nie mogą być zmienione po jej utworzeniu: opcja COMPACT STORAGE, opcja CLUSTERING ORDER. Baza danych Cassandra. Język CQL. 57/82 CREATE TABLE - opcja COMPACT STORAGE Od CQL w wersji 3.0 tabele zwarte (ang. compact) są przechowywane tak samo jak te niezwarte. Opcja COMPACT STORAGE jest przestarzała, zachowana tylko ze względu na kompatybilność wstecz. Nie używamy do tworzenia nowych tabel. W CQL wersji 4.0 opcja ta zostanie w ogóle usunięta. Baza danych Cassandra. Język CQL. 58/82 CREATE TABLE - opcja CLUSTERING ORDER Porządek sortowania jest określony przez kolumny grupujące, które narzucają porządek ułożenia wierszy w ramach partycji. Domyślnie jest to naturalny porządek sortowania - rosnący. Opcja CLUSTERING ORDER pozwala zmienić ten porządek na przeciwny dla jednej, wielu czy wszystkich kolumn. CLUSTERING ORDER przyjmuje listę kolumn grupujących ze słowami: ASC - porządek naturalny, rosnący, DESC - porządek przeciwny do naturalnego, malejący. Bez użycia opcji CLUSTERING ORDER wszystkie kolumny grupujące są uporządkowane tak, jakby miały ASC. Baza danych Cassandra. Język CQL. 59/82 CREATE TABLE - opcja CLUSTERING ORDER Trzy konsekwencje posiadania kolumn grupujących i opcji CLUSTERING ORDER: klauzula ORDER BY jest ograniczona tylko do kolejności zgodnej z kolumnami grupującymi albo przeciwnej do niej, np.: a | b | c ---+---+--0 | 0 | 4 0 | 1 | 9 0 | 2 | 2 0 | 3 | 3 // OK SELECT * SELECT * // BŁĄD SELECT * SELECT * // // // // row row row row 1 2 3 4 FROM t WHERE a=0 ORDER BY b ASC, c ASC; FROM t WHERE a=0 ORDER BY b DESC, c DESC; FROM t WHERE a=0 ORDER BY b ASC, c DESC; FROM t WHERE a=0 ORDER BY b DESC, c ASC; zmiana domyślnej kolejności wyświetlania wyników zapytania (bez klauzuli ORDER BY), zmiana kolejności sortowania wpływa nieznacznie na wydajność zapytań szybciej wykonywane są zapytania z porządkiem rosnącym. Baza danych Cassandra. Język CQL. 60/82 Tombstones i Garbage Collection (GC) Żądanie usunięcia danych w Cassandrze nie usuwa danych bezpośrednio. Zamiast tego są zapisywane dodatkowe dane nazywane tombstone (pl. nagrobek). Tombstone reprezentuje usunięte dane i wszystko co pojawiło się przed tombstone nie pojawia się w wynikach zapytań. Używa się tego rozwiązania ze względu na rozproszoną naturę Cassandry. Usuwanie danych bez tombstone: Mamy trzy węzły z replikacją, każdy ma dane oznaczone jako [A]. [A], [A], [A] Jeden z węzłów zawodzi i po usunięciu danych mamy stan jak poniżej: [], [], [A] Operacja reperacji może doprowadzić do przywrócenia danych [A] na usuniętych węzłach: [A], [A], [A] Baza danych Cassandra. Język CQL. 61/82 Tombstones i Garbage Collection (GC) Usuwanie danych z tombstone: Mamy trzy węzły z replikacją, każdy ma dane oznaczone jako [A]. [A], [A], [A] Jeden z węzłów zawodzi ale tym razem po usunięciu danych mamy dodatkową informację o tym co usunięto: [A, Tombstone[A]], [A, Tombstone[A]], [A] Operacja reperacji tym razem przekopiuje intormacje o tombstone do niesprawnego węzła: [A, Tombstone[A]], [A, Tombstone[A]], [A, Tombstone[A]] Przechowujemy informacje o usuniętych danych w tombstone. Żeby nie przechowywać danych w tombstone na zawsze istnieje parametr gc_grace_seconds dotyczący każdej tabeli w Cassandrze. Baza danych Cassandra. Język CQL. 62/82 Filtr Blooma I Filtr Blooma: struktura danych stworzona przez Burtona Blooma w 1970 roku, wydajny pod względem użycia pamięci, ma działanie probabilistyczne, czasem się myli, w prostej wersji pozwala tylko na dodawanie elementów, potrafi odpowiedzieć na pytanie czy element należy do zbioru, jeśli odpowie NIE, to się nie myli, jeśli odpowie TAK, to może się mylić, fałszywe potwierdzenie. jest m-bitową tablicą, używa k niezależnych, losowych funkcji haszujących o wartościach z przedziału [0, m), od wartości m, k, jakości funkcji haszujących oraz liczby przechowywanych elementów zależy prawdopodobieństwo wystąpienia błędu, przy k=1 mamy prostą tablicę haszującą Baza danych Cassandra. Język CQL. 63/82 Filtr Blooma II Filtr Blooma, przykład dla m=18 i k=3: na początku wszystkie bity są wygaszone (pusty zbiór), wstawianie elementu do zbioru: dla elementu oblicza się wartości dla wszystkich k funkcji, ustawia się wyznaczone k bitów, sprawdzenie czy element należy do zbioru: dla elementu obliczamy wartości wszystkich funkcji k, jeśli jakikolwiek bit jest nieustawiony to element na pewno nie należy do zbioru, jeśli wszystki bity są ustawione to element najprawdopodobniej należy do zbioru, ale nie ma pewności. Baza danych Cassandra. Język CQL. 64/82 CREATE TABLE - inne opcje Opcja comment Rodzaj prosta War. domyślna brak read_repair_chance prosta 0.1 dclocal_read_repair_chance gc_grace_seconds prosta prosta 0 864000(10 dni) bloom_filter_fp_chance prosta 0.00075 default_time_to_live prosta 0 compaction compression caching mapa mapa mapa osobny opis osobny opis osobny opis Baza danych Cassandra. Język CQL. Opis komentarz do tabeli, dowolna treść prawdopodobieństwo odpytywania dodatkowych węzłów ... czas, po którym zostaną usunięte obiekty tombstone, powinien wystarczyć na naprawę uszkodzonego węzła p-two fałszywego odczytu potwierdzającego dla filtru Blooma domyślny czas ważności tabeli (TTL) w sekundach omówione osobno omówione osobno omówione osobno 65/82 Perspektywa przetwarzania dużych ilości danych Przetwadzanie dużych ilości danych: dane wejściowe mogą mieć GB a nawet TB danych, na takich danych uruchamiamy wieloetapowe przetwarzanie danych map reduce, ze względu na wielkość danych - odczyt i zapis zdominują czas potrzebny na przetwarzanie, stąd - dowolny/swobodny dostęp do oczytu i zapisu nie wchodzi w grę, strumieniujemy zapis i odczyt danych. Baza danych Cassandra. Język CQL. 66/82 SSTable - Sorted String Table Sorted String Table jest plikiem zawierającym zbiór dowolnych posortowanych par klucz-wartość. Może zawierać powtarzające się klucze. Przeczytanie całego pliku od początku do końca daje nam indeks. Dla bardzo dużych plików można opcjonalnie stworzyć dodatkowy indeks klucz-przesunięcie. Wykorzystanie: dla przetwarzania bardzo dużych zbiorów danych (GB, TB), dodatkowo przetwarzanie w klastrze, wieloetapowe, tam gdzie zapis i odczyt danych zajmuje większość czasu, swobodny (dowolny) dostęp do danych nie jest najlepszą opcją, strumieniujemy zapis danych - koszt dostępu do danych jest amortyzowany. Baza danych Cassandra. Język CQL. 67/82 Szybki odczyt danych Szybki odczyt danych: dane zgromadzone na dysku w strukturach SSTable są niezmienne ponieważ zmiana czegoś na dysku wymaga duży zmian w posiadanych danych, bardzo dobrze sprawdzają się statyczne indeksy, przeczytanie indeksu pozwala łatwo znaleźć odpowiednie dane na dysku, można też zapisać dane tabeli SSTable w pamięci RAM - MemTable co tym bardziej ułatwi odczyt. Baza danych Cassandra. Język CQL. 68/82 Szybki zapis danych Szybki zapis danych: chcemy mieć szybki odczyt na co pozwala SSTable, ale też chcemy mieć szybki zapis, szybkie i wydajne zapisywanie danych dużo trudniej osiągnąć, jeśli wszystkie dane są w pamięci to zapis jest szybki, jeśli tabelę SSTable umieścimy w pamięci (MemTable) to łatwo i szybko się ją zapisuje, jeśli dane są niezmienne na dysku to również szybko da się je odczytać. 1 Indeksy tabel SSTable są zawsze przechowywane w pamięci. 2 Wszystkie zapisy odbywają się bezpośredno do struktury MemTable. 3 Odczyt szuka danych najpierw w MemTable, następnie w SSTable na dysku. 4 Co jakiś czas MemTable są zapisywane na dysku w SSTable. 5 Co jakiś czas SSTable są łączone razem - kompaktowanie. Baza danych Cassandra. Język CQL. 69/82 Szybki zapis danych Baza danych Cassandra. Język CQL. 70/82 Szybki zapis danych Baza danych Cassandra. Język CQL. 71/82 SSTable w Cassandrze SSTable - tabela kluczy - plik par klucz-wartość posortowanych po kluczach. SSTable dostarcza ciągłe, uporządkowane i niezmienne mapowanie od kluczy do wartości gdzie klucze i wartości są dowolnymi ciągami zanków. Każda tabela SSTable wewnętrznie składa się z sekwencji bloków (zwykle 64KB). W Cassandrze SSTable to trzy osobne pliki utworzone dla każdej rodziny kolumn: filtr Blooma, index, dane. Dodawanie nowego klucza do tabeli SSTable: serializacja indeksu (sortowanie kolumn po kluczu i serializacja kolumn filtrem blooma), serializacja danych (sortowanie kolumn, określenie sposobu serializacji i serializacja kolumn), zapis danych tabeli SSTable, zapis filtru blooma i indeksu dla danej tabeli SSTable. Baza danych Cassandra. Język CQL. 72/82 CREATE TABLE - opcje kompatkowania Opcje kompaktowania (ang. compaction) muszą mieć przynajmniej opcję class, która określa strategie pakowania. Dostępne klasy to: SizeTieredCompactionStrategy (STCS), LeveledCompactionStrategy (LCS), TimeWindowCompactionStrategy (TWCS). Można dostarczyć również własną strategie pakowania podająć całą ścieżkę do nazwy odpowiedniej klasy. Przykład: DROP TABLE t; CREATE TABLE t (a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH compaction = {'class': 'LeveledCompactionStrategy', 'enabled': true, 'tombstone_threshold': 0.4, 'log_all':true}; ALTER TABLE t WITH compaction = {'class': 'TimeWindowCompactionStrategy', 'enabled': false}; Baza danych Cassandra. Język CQL. 73/82 CREATE TABLE - opcje kompatkowania Wszystkie dostarczone strategie pakowania dostarczają zbiór wspólnych opcji jak i opcje dostępne tylko dla wybranych strategii. Wspólne opcje: enabled - domyślnie true, określa kiedy dodatkowe/drugorzędne pakowanie ma być włączone, tombstone_threshold - domyślnie 0.2, tombstone_compaction_interval - domyślnie 86400 s (1 dzień), 86400s - domyślnie false, pozwala na włączenie bardziej szczegłowych informacji o pakowaniu w plikach log, unchecked_tombstone_compaction - domyślnie false, only_purge_repaired_tombstone - domyślnie false, min_threshold - domyślnie 4, dolny limit tabel sstable zanim pakowanie zostanie przełączone, nie używane dla strategii (LCS), max_threshold - domyślnie 32, górny limit tabel sstable zanim pakowanie zostanie przełączone, nie używane dla strategii (LCS), Baza danych Cassandra. Język CQL. 74/82 CREATE TABLE - opcje kompresji Opcje kompresji (ang. compression) czy jest kompresja i jaka ona jest. Dostępne są następujące składowe opcji kompresji: class - domyślna wartość LZ4Compressor, określa algorytm kompresji dla tablicy; domyślnie dostępne są opcje: LZ4Compressor, SnappyCompressor and DeflateCompressor, można dostarczyć własny kompresor, enabled - domyślna wartość true, włącza/wyłącza kompresję tabeli, chunk_length_in_kb - domyślna wartość 64KB, dane na dysku przechowywane są w blokach i tak są też kompresowane, określamy tutaj wielkość bloku w KB, crc_check_chance - domyślna wartość 1.0, kompresowane bloki zawierają sumę kontrolną (zapobiega np. propagacji błędnych danych do innych węzlów serwera), która może być sprawdzana z różnym prawdopodobieństwem: 1.0 - zawsze, 0.0 - nigdy. Baza danych Cassandra. Język CQL. 75/82 CREATE TABLE - opcje kompresji, przykłady CREATE TABLE t (a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH compression = {'sstable_compression': 'DeflateCompressor', 'crc_check_chance': 0.8, 'chunk_length_kb': 128} DESC TABLE t; CREATE TABLE mpk.t ( a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH CLUSTERING ORDER BY (b ASC, c ASC) AND bloom_filter_fp_chance = 0.01 AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment = '' AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} AND compression = {'chunk_length_in_kb': '128', 'class': 'org.apache.cassandra.io.compress.DeflateCompressor'} AND crc_check_chance = 0.8 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.0 AND speculative_retry = '99PERCENTILE'; Baza danych Cassandra. Język CQL. 76/82 CREATE TABLE - opcje kompresji, przykłady CREATE TABLE t (a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH compression = {'enabled':false}; CREATE TABLE t (a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH compression = {'sstable_compression': 'DeflateCompressor', 'crc_check_chance': 0.8, 'chunk_length_kb': 128} CREATE TABLE t (a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH compression = {'class': 'LZ4Compressor', 'crc_check_chance': 0.5, 'chunk_length_kb': 64}; CREATE TABLE t (a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH compression = {'class': 'SnappyCompressor', 'crc_check_chance': 0.0, 'chunk_length_kb': 32}; Baza danych Cassandra. Język CQL. 77/82 CREATE TABLE - opcje buforowania Opcje buforowania (ang. caching ) pozwalają na konfigurowanie: buforowania kluczy, buforowania wierszy. keys - domyślna wartość ALL, określa czy mają być buforowane klucze dla tej tablicy, możliwe wartości: ALL i NONE, rows_per_partition - domyślna wartość NONE, określa liczbę wierszy, które mają być buforowane dla każdej partycji; podanie liczby całkowitej n oznacza, że n pierwszych wierszy pobranych dla danej partycji będzie buforowanych; inne możliwe wartości to NONE i ALL. Przykład: CREATE TABLE t ( a int, b int, c int, PRIMARY KEY (a, b, c) ) WITH caching = {'keys': 'NONE', 'rows_per_partition': 100}; Baza danych Cassandra. Język CQL. 78/82 ALTER TABLE Polecenie ALTER TABLE może: zmienić typ kolumny w tabeli, dodać kolumny do tabeli, usunąć kolumnę(y) z tabeli, kolumna usuwana natychmiast ale dane nie od razu, zmienić niektóre opcje tabeli (opcja WITH). alter_table_statement ::= alter_table_instruction ::= ALTER TABLE table_name alter_table_instruction ALTER column_name TYPE cql_type | ADD column_name cql_type ( ',' column_name cql_type )* | DROP column_name ( column_name )* | WITH options ALTER TABLE addamsFamily ALTER lastKnownLocation TYPE uuid; ALTER TABLE addamsFamily ADD gravesite varchar; ALTER TABLE addamsFamily WITH comment = 'A most excellent and useful table' AND read_repair_chance = 0.2; Baza danych Cassandra. Język CQL. 79/82 Możliwości zmiany typów CQL Typy danych w CQL mogą być konwertowane tylko zgodnie z poniższą tabelą: Istniejący typ timestamp ascii, bigint, boolean, date, decimal, double, float, inet, int, smallint, text, time, timestamp, timeuuid, tinyint, uuid, varchar, varint int ascii, varchar bigint bigint timeuuid ascii, text bigint, int, timestamp Może być zmieniony na bigint blob date text time timestamp uuid varchar varint Ograniczenia dla kolumn odpowiedzialnych za współdzielenie: Istniejący typ ascii, text, varchar ascii, varchar ascii, text Baza danych Cassandra. Język CQL. Może być zmieniony na blob text varchar 80/82 TRUNCATE i DROP TABLE Polecenie TRUNCATE pozwala usunąć całą zawartość tabeli ale ona sama pozostaje. Polecenie TRUNCATE TABLE foo jest dla spójności z innymi poleceniami DDL ale tabela jest jedynym obiektem, który można wyczyścić. truncate_statement ::= TRUNCATE [ TABLE ] table_name Polecenie DROP TABLE usuwa tabelę. Usunięcie tabeli skutkuje natychmiastowym i nieodwracalnym usunięciem samej tabeli wraz z ze wszsystkimi zawartymi w niej danymi. Wykorzystanie IF EXISTS zapobiega przed wystąpieniem błędu, jeśli tabele o podanej nazwie nie istała. drop_table_statement ::= Baza danych Cassandra. Język CQL. DROP TABLE [ IF EXISTS ] table_name 81/82 Źródła https://www.g2crowd.com/press-release/ best-nosql-databases-fall-2015/ https://en.wikipedia.org/wiki/Apache_Cassandra http://cassandra.apache.org/doc/latest/ https://docs.datastax.com/en/cql/3.1/cql/cql_intro_c.html Baza danych Cassandra. Język CQL. 82/82