Wybór klucza partycji
Jestem niezdecydowany, czy lepiej, pod względem wydajności, użyć bardzo często współdzielonej wartości kolumny (jak Country) jako klucza partycji dla złożonego klucza podstawowego, czy raczej unikalnej wartości kolumny(jak Last_Name).
Patrząc na dokumentację Cassandry 1.2 o indeksach rozumiem to:
"Kiedy używać indeksu : Wbudowane indeksy Kasandry są najlepsze na stole posiadanie wielu wierszy zawierających wartość zindeksowaną. tym bardziej unikalne wartości, które istnieją w konkretnej kolumnie, tym więcej kosztów będziesz mieć średnio do odpytywania i utrzymywania indeksu. na przykład, Załóżmy, że masz tabelę użytkowników z miliardem użytkowników i chcesz zajrzeć up użytkowników według stanu, w którym żyli. wielu użytkowników będzie dzielić to samo wartość kolumny dla stanu (np.). To będzie dobry kandydat do indeksu."
"Kiedy nie używać indeksu : Nie używaj indeksu do odpytywania ogromnej ilości rekordów o małe liczba wyników. Na przykład, jeśli utworzysz indeks na kolumnie który ma wiele odrębnych wartości, zapytanie między polami spowoduje wielu szuka bardzo niewielu rezultatów. w tabeli z miliardem użytkowników, wyszukiwanie użytkowników według ich adresu e-mail (wartość, która jest zazwyczaj unikalne dla każdego użytkownika) zamiast według ich stanu, może być bardzo nieefektywne.[[11]} prawdopodobnie bardziej wydajne byłoby ręczne utrzymywanie tabelę jako formę indeksu zamiast używania Cassandra wbudowany indeks. W przypadku kolumn zawierających unikalne dane jest to czasami dobra wydajność, aby używać indeksu dla wygody, tak długo, jak wolumen zapytań do tabeli z indeksowaną kolumną jest umiarkowany i nie pod stałym obciążeniem."
Patrząc na przykłady z CQL SELECT dla
"zapytując złożone klucze podstawowe i sortując wyniki ", widzę coś w rodzaju UUID używanego jako klucz partycji... co wskazywałoby, że jest lepiej użyć czegoś unikalnego?
3 answers
Indeksowanie w zapisanej dokumentacji odnosi się do indeksów drugorzędnych. W Cassandrze istnieje różnica między indeksami pierwotnym i wtórnym. W przypadku indeksu wtórnego rzeczywiście źle byłoby mieć bardzo unikalne wartości, jednak dla składników w kluczu podstawowym zależy to od tego, na jakim komponencie się skupiamy. W kluczu podstawowym mamy następujące składniki:
Klucz podstawowy (klucz partycjonujący, klucz klastrujący_1 ... clustering key_n)
The klucz partycjonowania jest używany do dystrybucji danych między różnymi węzłami, a jeśli chcesz, aby twoje węzły były zrównoważone (tj. dobrze rozmieszczone dane w każdym węźle), chcesz, aby twój klucz partycjonowania był jak najbardziej losowy. Dlatego przykład, który masz używa uuid.
Klucz klastrowy jest używany do porządkowania , aby wyszukiwanie kolumn z określonym kluczem klastrowym było bardziej efektywne. Tam, gdzie chcesz, aby twoje wartości nie były wyjątkowe i gdzie byłoby wydajność hit, jeśli unikalne wiersze były częste.
Dokumenty cql mają dobre wyjaśnienie, co się dzieje.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-08-12 08:12:59
Jeśli używasz cql3, podaj rodzinę kolumn:
CREATE TABLE table1 (
a1 text,
a2 text,
b1 text,
b2 text,
c1 text,
c2 text,
PRIMARY KEY ( (a1, a2), b1, b2) )
);
Definiując klucz podstawowy ((a1, a2, ...), b1, b2, ... )
Oznacza to, że:
A1, a2, ... są polami używanymi do tworzenia klucza wiersza w celu:
- określ, w jaki sposób dane są partycjonowane
- określ, co jest fizycznie przechowywane w jednym wierszu
- określany jako klucz wiersza lub klucz partycji
B1, b2, ... są polami rodziny kolumn używanymi do klastrowania klucza wiersza w kolejności do:
- tworzenie zestawów logicznych wewnątrz jednego wiersza
- pozwalają na bardziej elastyczne Schematy wyszukiwania, takie jak range range
- określany jako klucz kolumnowy lub klucz klastra
Wszystkie pozostałe pola są skutecznie multipleksowane / duplikowane dla każdej możliwej kombinacji klawiszy kolumn. Poniżej przykład dotyczący kluczy kompozytowych z kluczami partycji i kluczami klastrowania.
Jeśli chcesz użyć zapytań range, możesz użyć indeksów drugorzędnych lub (zaczynając od cql3) pola te Można zadeklarować jako klucze klastrowania. Pod względem prędkości posiadanie ich jako klucza klastrowego utworzy jeden szeroki wiersz. Ma to wpływ na szybkość, ponieważ można pobrać wiele wartości klucza klastrowania, takich jak:
select * from accounts where Country>'Italy' and Country<'Spain'
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-03 15:44:02
Jestem pewien, że otrzymałbyś odpowiedź, ale nadal może Ci to pomóc w lepszym zrozumieniu.
CREATE TABLE table1 (
a1 text,
a2 text,
b1 text,
b2 text,
c1 text,
c2 text,
PRIMARY KEY ( (a1, a2), b1, b2) )
);
Tutaj klucze partycji to (a1, a2), a klucze wiersza to b1, b2.
Kombinacja zarówno klawiszy partycji, jak i klawiszy wiersza musi być unikalna dla każdego nowego rekordu.
Powyższy klucz podstawowy można zdefiniować w ten sposób.
Node< key, value>
Node<(a1a2), Map< b1b2, otherColumnValues>>
Jak wiemy klucz partycji jest odpowiedzialny za dystrybucję danych przez twoje węzły.
Więc jeśli wstawiasz 100 rekordów w table1 z tymi samymi kluczami partycji i różnymi kluczami wiersza. będzie przechowywać dane w tym samym węźle, ale w różnych kolumnach.
Logicznie możemy reprezentować w ten sposób.
Node<(a1a2), Map< string1, otherColumnValues>, Map< string2, otherColumnValues> .... Map< string100, otherColumnValues>>
Więc rekord będzie przechowywany kolejno w pamięci.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-17 14:10:31