Špatné : Rozdělení
jednou z těžkých věcí, na které si nejprve zvyknete, je to, že bez indexů mohou být dotazy, které pokrývají řádky, (velmi) špatné. Když si však vzpomeneme na náš model úložiště, není to překvapivé. Strategie, kterou Cassandra používá k distribuci řádků mezi hostiteli, se nazývá rozdělení.
rozdělení je akt vyřezávání rozsah rowkeys přiřazení je do „token ring“, který také přiřazuje odpovědnost za segment (tj. oddíl) rozsahu rowkey každému hostiteli. Pravděpodobně jste to viděli, když jste inicializovali cluster pomocí „tokenu“. Token dává hostiteli umístění podél tokenového kruhu, který přiřazuje odpovědnost za část rozsahu tokenů. Rozdělení je akt mapování rowkey do rozsahu tokenu.
existují dva primární rozdělovače: náhodné a zachování pořadí. Jsou vhodně pojmenovány. RandomPartitioner hash rowkeys do tokenů. S RandomPartitioner, token je hash rowkey. To dělá dobrou práci rovnoměrně distribuovat svá data přes sadu uzlů, ale dělá dotazování rozsah rowkey prostoru neuvěřitelně obtížné. Pouze z hodnoty“ start rowkey „a hodnoty“ end rowkey “ Cassandra nemůže určit, jaký rozsah prostoru tokenu potřebujete. V podstatě je třeba provést „skenování tabulky“, aby odpověděl na dotaz, a „skenování tabulky“ v Cassandře je špatné, protože k zodpovězení dotazu musí jít na každý stroj (pravděpodobně na všechny stroje, pokud máte dobrou hašovací funkci).
dobrý: sekundární indexy
Cassandra poskytuje nativní indexovací mechanismus v sekundárních indexech. Sekundární indexy pracují z hodnot sloupců. Deklarujete sekundární index v rodině sloupců. Datastax má dobrou dokumentaci o použití. Pod kapotou Cassandra udržuje jako index „skrytou rodinu sloupců“. Vzhledem k tomu, že Cassandra neudržuje informace o hodnotě sloupce v žádném uzlu a sekundární indexy jsou na hodnotě sloupců (spíše než rowkeys), musí být dotaz stále odeslán do všech uzlů. Sekundární indexy se navíc nedoporučují pro sady s vysokou kardinálností. Ještě jsem se nedíval, ale předpokládám, že je to kvůli datovému modelu použitému v rámci „skryté rodiny sloupců“. Pokud rodina skrytých sloupců ukládá řádek na jedinečnou hodnotu (s rowkeys jako sloupci), pak by to znamenalo skenování řádků a určení, zda jsou v rozsahu dotazu.
z Edovy prezentace:
- nedoporučuje se pro vysoké hodnoty kardinality (např. časová razítka,data narození,klíčová slova atd.)
- vyžaduje alespoň jedno srovnání rovnosti v dotazu-není skvělé pro méně než/větší než/rozsah dotazů
- netříděné-výsledky jsou v pořadí tokenů, nikoli pořadí hodnot dotazu
- omezeno na vyhledávání v datových typech, Cassandra nativně rozumí
se vším, co bylo řečeno, sekundární indexy fungují po vybalení z krabice a měli jsme dobrý úspěch při jejich používání na jednoduchých hodnotách.
ošklivý: Do-It-Yourself (DIY) / Wide-Rows
nyní je krása v oku pozorovatele. Jednou z krásných věcí na NoSQL je jednoduchost. Konstrukce jsou jednoduché: klíčové prostory, rodiny sloupců, řádky a sloupce. Udržet to jednoduché však znamená, že někdy budete muset vzít věci do svých rukou.
to je případ širokoúhlých indexů. Využití úložného modelu Cassandry, je snadné vytvořit si vlastní indexy, kde se každý řádek klíče stává sloupcem v indexu. To je někdy těžké dostat hlavu kolem, ale umožňuje si představit, že máme případ, kdy chceme vybrat všechny uživatele v PSČ. Hlavní rodina sloupců uživatelů je zadána na userid, psČ je sloupec v každém řádku uživatele. Mohli bychom použít sekundární indexy, ale existuje poměrně málo PSČ. Místo toho bychom mohli udržovat rodinu sloupců s jedním řádkem s názvem „idx_zipcode“. Do tohoto řádku formuláře „zipcode_userid“bychom pak mohli zapsat sloupce. Vzhledem k tomu, že sloupce jsou uloženy v řazeném pořadí, je rychlé dotazovat se na všechny sloupce, které začínají „18964“ (např. můžeme použít 18964_ a 18964_ZZZZZ jako počáteční a koncové hodnoty).
jednou zjevnou nevýhodou tohoto přístupu je, že řádky jsou na hostiteli samostatné. (opět s výjimkou replik) to znamená, že všechny dotazy zasáhnou jeden uzel. Ještě jsem na to nenašel dobrou odpověď.