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

Podobne dokumenty