Úvod do datového modelu v Cassandře
Apache Cassandra se stala jednou z nejsilnějších databází NoSQL. Je to správná volba, pokud chcete vysokou dostupnost a škálovatelnost bez kompromisů s výkonem - zejména pro aplikace, které si nemohou dovolit ztrácet data. V tomto tématu se dozvíme o datovém modelu v Cassandře.
Inženýři společnosti Cassandra dnes patří mezi špičkové odborníky v oblasti techniky. Společnosti jako Netflix, Instagram a Apple používají Cassandra k zajištění vysoce individualizovaného zákaznického zážitku. Abyste dosáhli správného výkonu, musíte pečlivě navrhnout schéma specifické pro daný obchodní problém. V tomto článku se podíváme na datový model Cassandra, který se výrazně liší od toho, co vidíme v RDBMS.
Pravidla datového modelu Cassandra
Jednoduše řečeno, datový model je logická struktura databáze. Popisuje, jak jsou data ukládána a zpřístupňována, a vztahy mezi různými typy dat.
Výběr správného datového modelu může být nejtěžší součástí používání databáze NoSQL, jako je Cassandra. Jak jsem již zmínil dříve, modelování dat v Cassandře se liší od toho, co vidíme v RDBMS.
Klíč oddílu a klíč clusteru jsou pojmy, o kterých by měl vědět kdokoli, kdo jedná s Cassandrou. Než se pustíme do základních pravidel modelování dat v Cassandře, podívejme se rychle na to, co tyto pojmy znamenají,
Rozdělit
Cassandra je distribuovaná databáze, ve které jsou data rozdělena a uložena na různých uzlech v klastru. Data jsou rozdělena pomocí klíče oddílu - může to být jedno nebo více datových polí. Tento klíč oddílu se používá k vytvoření hashovacího mechanismu pro rovnoměrné šíření dat ve všech uzlech.
Cluster
Klastr je kolekce uzlů, které představují jednu logickou databázi. Klastrovací klíč se skládá z jednoho nebo více polí, která se používají k seskupování dat do oddílu.
V této tabulce restaurací budou data rozdělena pomocí country_code, state_name a city_name a v rámci těchto partition budou data seskupena a tříděna podle open_data a restaurant_name.
Nyní se podívejme na dvě pravidla pro modelování dat, na která byste měli mít na paměti.
- Data jsou distribuována rovnoměrně v klastru
- Přečtěte si z co nejméně oddílů
Podívejme se, co se tato pravidla snaží sdělit
- Víme, co je klastr správný? Klastr se skládá z více uzlů. Chceme rozdělit data mezi tyto uzly tak, aby každý uzel měl zhruba stejné množství dat. Jak víme, data jsou rozdělena do různých uzlů pomocí hash klíče pro oddíl (který je prvním klíčem primárního klíče), takže zkráceně „měli byste vybrat dobrý primární klíč“.
- Každý oddíl je umístěn v jiném uzlu, takže při načítání dat se chcete ujistit, že data jsou načtena z co nejméně oddílů. Pokud váš dotaz vyžaduje data z různých oddílů, bude vydán příkaz do samostatných uzlů, aby vám ta data, která budou režijní a vést k latenci.
Klíčem k efektivnímu datovému modelu by byla rovnováha mezi těmito dvěma pravidly.
Zvládněte vztahy v Cassandře
Jedna věc, kterou je třeba mít na paměti, je modelování dat v Cassandře, které se provádí pomocí přístupu založeného na dotazu, na rozdíl od RDBMS, kde nejprve identifikujete entity, vytvářejte tabulky a poté vytvářejte dotazy pomocí JOINS k načtení dat.
Jednoduše řečeno, nemodelujeme kolem vztahů nebo objektů, modelujeme kolem dotazů.
1. Vztah jeden ku druhému
Uvažujte na univerzitě, že se student může přihlásit pouze na jeden seminář. Toto je vztah jeden ku jednomu. Při dodržení pravidla číslo 1 myslíme na dotazy, které chceme. Chci hledat seminář, kterého se student účastní. V tomto případě uděláme jen jednu tabulku. Tabulka by měla obsahovat podrobnosti o studentovi a podrobnosti o semináři.
2. Vztah jeden k mnoha
Ve stejném kontextu, co kdybych chtěl hledat všechny studenty, kteří se účastní semináře. Namísto použití stejné tabulky a iterace nad každým řádkem k získání jména studenta pro tento konkrétní seminář, mohu vytvořit další tabulku, která rozdělí data podle názvu semináře. Když tedy zadám dotaz, zasáhne to pouze jeden uzel, a ne jít do všech uzlů, aby získal název semináře.
3. Vztah Mnoho k mnoha
Nyní se podívejme, že student se může zúčastnit mnoha seminářů a seminář se může zúčastnit mnoho studentů. Zde máme mnoho až mnoho vztahů. V takovém případě můžete výše uvedené dvě tabulky využít k vytváření dotazů, aniž byste museli provádět režii složitých dotazů pomocí spojení, které byste obvykle dělali v RDBMS.
Význam Cassandry
S rychlým rozšířením digitálních dat je stále důležitější mít vysoce škálovatelnou databázi odolnou proti chybám. Dovolte mi vyjmenovat několik bodů, proč byste měli používat Cassandru
- Osvětlení operací rychlého čtení: Diskutovali jsme o tom, jak správná modelování vašich dat může optimalizovat operace čtení pomocí velkého měřítka.
- Odolnost proti chybám: Data jsou replikována napříč uzly, takže i když jeden uzel klesá, vaše data jsou v bezpečí.
- Uživatelské ladění: Cassandru můžete nastavit tak, aby pracovala podle vaší pracovní zátěže. Pokud píšete mnoho dat, například protokolování, můžete je vyladit tak, aby zvládly systémy náročné na zápis. K dispozici je několik dalších možností ladění.
- Řešení velkých objemů dat: Na základě velikosti klastru může Cassandra zvládnout obrovské objemy dat.
Jak modelovat data v Cassandře?
Těmito kroky následuje dobré modelování dat
- Konceptualizujte dotazy požadované vaší aplikací
- Vytváření tabulek k uspokojení těchto dotazů
Před použitím těchto pravidel je třeba mít na paměti jednu věc: „Zaměřujeme se na optimalizaci našich operací čtení, i když to vyžaduje duplikování dat“. Můžeme mít mnoho tabulek, které mohou obsahovat téměř podobná data.
Nyní zvažte, zda chceme databázi, která ukládá informace o restauracích. Pojďme omezit, že názvy restaurací musí být jedinečné.
Níže uvedenou tabulku lze použít, když chceme vyhledat na základě názvu restaurace:
Nyní, pokud chceme vyhledat restaurace pro konkrétní umístění, napíšeme dotaz, který iteruje přes všechny řádky a načte názvy restaurací.
Místo toho, s ohledem na pravidlo č. 2, můžeme snadno vytvořit další tabulku, která bude sloužit našim potřebám.
Nyní budou naše data rozdělena tak, že uzel v klastru bude mít restaurace pro konkrétní umístění. Tím se optimalizují naše dotazy pro čtení, protože vyhledávání dotazů proběhne pouze na jednom uzlu s mnohem menšími řádky než první tabulka, kterou jsme vytvořili.
Co kdybychom chtěli prohledat restaurace v konkrétním městě, můžeme vytvořit jinou tabulku, než iterovat skrz všechny řádky v jednom oddílu výše uvedené tabulky.
Závěr
V tomto článku jsem popsal několik osvědčených postupů, které můžete sledovat, jak přistupovat k modelování dat v Cassandře. Pokud těmto konceptům rozumíte a dokážete efektivně rozpoznat druh dotazů, které vaše aplikace potřebuje, můžete navrhnout skvělý datový model, abyste z vaší databáze získali vysoký výkon.
Doporučené články
Toto je průvodce datovým modelem v Cassandře. Zde diskutujeme o tom, jak modelovat naše data v Cassandře spolu s pravidly a významem datových modelů Cassandra. Další informace naleznete také v dalších navrhovaných článcích -
- Co je datové modelování?
- Datové modely v DBMS
- Rozhovory s otázkami modelování dat
- Cassandra Data Modeling