špatný způsob, jak škálovat až Cassandra DB při sekundární indexy jsou na místě

Cassandra je moje oblíbená (není řízen) databáze pro mnoho důvodů: nemá jediný bod selhání (SPoF), podporuje multi-region, dobré pro čtení a zápis ops, flexibilní, o tom číst a psát konzistenci úrovně, váhy lineárně a ne příliš složité zvládnout pro den-to-day operace.

Jako každá databáze, měli byste použít Cassandra na základě vašeho data access vzory, takže pokud budete potřebovat flexibilní databáze pro ad-hoc dotazy nebo dostatečně adaptabilní pro databáze neustále změny modelu, měli byste zvážit další možnosti.

Cassandra je sloupec orientovaný DB a je to opravdu silný, když máte vaše datové dotazy již definovány. Datastax, společnost, která podporuje Cassandru, doporučuje, abyste měli začít tím, že navrhnete své dotazy a poté datový model v Cassandře. Navzdory skutečnosti, že vaše sloupcová struktura podporuje Cassandra mnoho datových struktur jako typ sloupců,například Mapy.

Cassandra je primární klíč databáze, což znamená, že vaše data jsou trvalé a organizované kolem clusteru na základě hash hodnota (oddíl, klíč) primární klíč. U tabulek, které mají více než jeden PK, Cassandra považuje pouze první část PK za klíč oddílu. Více o kompozitních klíčích naleznete zde.

abychom byli jasnější, vraťme se k jedné z nejdůležitějších vlastností Cassandra DB: je to architektura a skutečnost, že nemá SPoF.

Cluster Cassandra se skládá z uzlů (3 nebo více) a tyto uzly společně tvoří kruh uzlů:

Každý uzel na Cassandra clusteru pracuje “nezávisle”, ale různé uzly by mohly ukládat stejná data odpovídajícím způsobem replikační faktor (RF) konfigurace konfigurace clusteru.

Chcete-li vědět, kde (který uzel) vaše data přetrvávají, Cassandra používá hodnotu hash (token) vypočtenou pomocí konzistentní hashovací funkce pomocí sloupce PK dané tabulky.

Při spuštění dotazu, koordinátor uzlu (obvykle nejblíže vaší instance aplikace), bude hledat to, co uzly v kruhu mít vaše data, tímto způsobem, pokud jeden uzel je dole z nějakého důvodu, další uzel by mohl sloužit své údaje (RF ≥2). To je kouzlo přístupu bez mistra, kde každý uzel v kruhu je stejný, pokud jde o čtení a zápis.

tento koncept o PK a faktoru replikace je velmi důležitý pro pochopení toho, jak škálovat Cluster Cassandra, když je vaše aplikace v podmínkách vysokého zatížení.

sekundární indexy

Cassandra má také pojem sekundární indexy. V relačních databázích můžete mít v dané tabulce mnoho indexů, náklady na sekundární index jsou spojeny s operacemi zápisu, nikoli pro operace čtení. V Cassandře to není pravda.

sekundární indexy v Cassandře by mohly být užitečné a lákavé, když se váš datový model změnil a potřebujete dotaz na základě nového sloupce.

V tomto smyslu, se sekundární index, můžete spustit dotaz jako, že:

SELECT * FROM my_table KDE SECONDARY_INDEX = ‘hodnota’;

problém o použití Sekundární Index

Představte si tento scénář: jste v Blackfriday/CyberMonday a vaše Cassandra clusteru trpí vrchol události, a budete muset přidat více uzlů k rozsahu databáze, vyvažování lepší svůj provoz a… přežít. Fajn, že?

normálně je to normální situace ve vysoce škálovatelné aplikaci. Ale co když vaše aplikace spouští dotazy pomocí sekundárního indexu?

jo, máte pravdu.

Pamatujete si, když jsem řekl, že Cassandra distribuuje data v kruhu pomocí klíče partition? To se již děje, ale problém je, když do dotazu zadáte sekundární index. Sekundární indexy nejsou součástí klíče oddílu a Cassandra ví, kde žijí vaše data prostřednictvím klíče oddílu. Když spustíte dotaz, který používá tento druh indexu, Cassandra hledá každý uzel ve vašem kruhu a snaží se uspokojit váš dotaz.

reálný scénář

během Blackfriday byly naše aplikace s vysokým zatížením. Mnoho a mnoho zákazníků, kteří chtějí těžit z obrovských slev poskytovaných událostí Blackfriday.

podívali jsme se na náš APM a veškerá analýza nás vedla k naší vytrvalosti, v tomto případě Cassandra DB. Máme dlouhé období latence, ale ne pro každou žádost, jen pro některé.

snažíme se udržet věci zpět do normálního stavu, naším prvním manévrem bylo přidat další uzly do našeho clusteru Cassandra.

přidali jsme a stále trpíme problémy s latencí. Otázka zněla: proč se to stále děje?

mýlili jsme se. Byl to zjednodušený závěr a nestarali jsme se o jeden velmi důležitý detail: toto chování se nedělo ve všech žádostech, ale v některých z nich.

pokud jste přemýšleli o sekundárním indexu, bingo! To byl přesně ten problém.

Přidávání uzlů by nikdy vyřešit problém, protože problém se nevztahuje na všechny dotazy příjezdu do databáze, problém byl v některých a to byly ty skutečné degradaci výkonu databáze. Byla to Paretova věc.

podrobně popisující problém a způsob jeho zmírnění

V jednom okamžiku před událostí Blackfriday jsme potřebovali změnit náš datový model. Regionalizovali jsme naši aplikaci a region zákazníka pro nás začal být důležitou věcí, potřebovali jsme dotazovat data na základě produktu nebo regionu.

při Pohledu zpět a spojující tečky, můžeme si uvědomit, že jsme byli velmi drahé o provádění, jak jsme chtěli, aby odrážely toto nové chování nejen v API Vrstva (nový dotaz param), ale také způsobem, jakým jsme přístupná data v Cassandře.

a proč jsme byli tak vzácní? Protože i vzhledem k tomu, že se náš dotazovací čas tolik nezvyšoval, udělali jsme změnu.

Že provádění není pouze zvýšení našeho času dotazu pomocí sekundární index, ale také přineslo více problémů podle nám rozšířit Cassandra infrastruktury. Když jsme do našeho clusteru přidali více uzlů, znamenalo to, že více uzlů vyhledalo data, takže problém exponenciálně rostl.

abychom tento problém zmírnili, vzali jsme zpět počet uzlů, které jsme měli dříve, a zvýšili faktor replikace pro většinu našich uzlů v klastru.

také jsme změnili naši úroveň konzistence čtení tak, aby byla méně konzistentní. Používali jsme * QUORUM a místo toho jsme se změnili na ONE. To nám pomohlo snížit zatížení v uzlech.

jak jsme zmrazili naše aplikace dny před událostí, věděli jsme, že nemáme nová data (operace zápisu) a data budou konzistentní v jejich současném stavu.

dny po a DB model řešení

Jako součást konečného řešení, které jsme potřebovali k (re), že o naše databáze model a vrátit zpět změny, které jsme udělali jako cestu ke zmírnění průběhu akce.

Před akcí jsme byly pomocí ID produktu (PID)jako klíč oddílu, což bylo dobré rozhodnutí, protože PID má dobré atributy být PK vzhledem ke své povaze o tom, že pořadové číslo (vysoké mohutnost), a v tom případě šíření dat rovnoměrně po clusteru.

o novém poli “region” jsme využili datový typ Cassandra collections a použili jsme mapu pro každou oblast jako sloupec v naší tabulce produktů.

sekundární indexy jsou vždy špatný nápad?

krátká odpověď zní ne.

vysvětlení trochu lepší, existují dva druhy indexů v Cassandra: místní a globální indexy.

místní index, jak název napovídá, je druh indexu, který existuje pouze lokálně, to znamená v uzlu. Když vytvoříte sekundární index, Cassandra vytvoří novou (skrytou) tabulku, kde se sekundární stane primárním klíčem v této tabulce. Viditelnost této nové tabulky je z hlediska uzlu, nikoli kruhu (clusteru). To je případ sekundárních indexů.

na druhou stranu, globální index má viditelnost kruhu prostřednictvím klíče oddílu, takže Cassandra ví, kde jsou vaše data v kruhu prostřednictvím tohoto klíče oddílu.

sekundární indexy mohou být alternativou, pokud máte v dotazu oba: primární a sekundární indexy. V takovém případě Cassandra ví, kde jsou vaše data umístěna (který uzel) pomocí klíče partition a poté vyhledá místní tabulku v uzlu, který odkazuje na (místní) sekundární indexy.

existují také některé další nuance o sekundárních indexech, které jsou zde velmi dobře vysvětleny, ale nejlepším postupem je vyhnout se jim denormalizací datového modelu.