Cassandra Příklad datového modelu s jednoduchou databází

Ačkoli Cassandra dotazovací jazyk se podobá SQL jejich metody modelování dat jsou zcela odlišné.

In Cassandra, může špatný datový model snížit výkon, zvláště když se uživatelé snaží implementovat koncepty RDBMS Cassandra. Nejlepší je mít na paměti několik níže uvedených pravidel.

Cassandra Pravidla datového modelu

In Cassandra, zápisy nejsou drahé. Cassandra nepodporuje spojení, seskupení podle, klauzuli OR, agregace atd. Takže musíte svá data ukládat tak, aby je bylo možné zcela získat. Tato pravidla je tedy třeba mít na paměti při modelování dat Cassandra.

Maximalizujte počet zápisů

In Cassandra, píše jsou velmi levné. Cassandra je optimalizován pro vysoký výkon zápisu. Snažte se proto maximalizovat počet zápisů pro lepší výkon čtení a dostupnost dat. Mezi zápisem a čtením dat existuje kompromis. Optimalizujte tedy výkon čtení dat maximalizací počtu zápisů dat.

Maximalizujte duplikaci dat

Denormalizace dat a duplikace dat jsou defacto Cassandra. Místo na disku není dražší než paměť, zpracování CPU a provoz IO. Jak Cassandra je distribuovaná databáze, takže duplikace dat poskytuje okamžitou dostupnost dat a žádný jediný bod selhání.

Cassandra Cíle datového modelování

Při modelování dat byste měli mít následující cíle Cassandra:

Rozložte data rovnoměrně kolem Cluster

Chcete stejné množství dat na každém uzlu Cassandra ClusterData jsou rozložena do různých uzlů na základě klíčů oddílů, což je první část primárního klíče. Zkuste proto jako klíč oddílu zvolit sloupec s vysokou mohutností pro rovnoměrné rozložení dat v rámci clusteru.

Minimalizujte počet oddílů čtených při dotazování na data

Oddíl je skupina záznamů se stejným klíčem oddílu. Když je zadán dotaz na čtení, shromažďuje data z různých uzlů z různých oddílů.

Pokud bude oddílů mnoho, je třeba navštívit všechny tyto oddíly, aby bylo možné shromáždit data dotazu.

To neznamená, že by se oddíly neměly vytvářet. Pokud jsou vaše data velmi velká, nemůžete takové obrovské množství dat uchovávat na jednom oddílu. Jeden oddíl se zpomalí.

Zkuste tedy zvolit vyvážený počet oddílů.

Dobrý primární klíč Cassandra

Oba výše uvedené cíle se redukují na jedno rozhodnutí, takže dvě níže uvedená schémata ukazují stejnou tabulku se špatným klíčem a poté s klíčem správným.

Vezměme si příklad a zjistíme, který primární klíč je správný.

Zde je tabulka MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY (SongId, SongName)
);

Ve výše uvedeném příkladu tabulka MusicPlaylist,

• SongId je klíč oddílu a
• Název skladby je sloupec shlukování
• Data budou seskupena na základě názvu skladby (SongName). Pro každé ID skladby (SongId) bude vytvořen pouze jeden oddíl a protože každá skladba má odlišný identifikátor, každý oddíl obsahuje jeden řádek.

Načítání dat bude u tohoto datového modelu pomalé kvůli špatnému primárnímu klíči.

Zde je další tabulka MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY ((SongId, Year), SongName)
);

Ve výše uvedeném příkladu tabulka MusicPlaylist,

• SongId a Year jsou klíčem oddílu a
• Název skladby je sloupec shlukování.
• Data budou seskupena na základě názvu skladby. V této tabulce bude každý rok vytvořen nový oddíl. Všechny písně roku budou na stejném uzlu. Tento primární klíč bude velmi užitečný pro data.

Naše načítání dat bude díky tomuto datovému modelu rychlé.

Modelujte svá data Cassandra

Při modelování vašich dotazů je třeba mít na paměti následující věci:

Určete, jaké dotazy chcete podporovat

Nejprve si určete, jaké dotazy chcete.

Například potřebujete?

• Připojuje
• Skupina vytvořená
• Filtrování podle kterého sloupce atd.

Vytvořte tabulku podle vašich dotazů

Vytvořte tabulku podle vašich dotazů. Vytvořte tabulku, která uspokojí vaše dotazy. Pokuste se vytvořit tabulku tak, aby bylo potřeba načíst minimální počet oddílů.

Následující tři části aplikují tento princip na tři typy vztahů, které se nacházejí téměř v každém schématu.

Zvládání vztahu jeden k jednomu Cassandra

Vztah jedna ku jedné znamená, že dvě tabulky mají shodu jedna ku jedné. Student si například může zapsat pouze jeden kurz a já chci na studentovi vyhledat, ve kterém kurzu je konkrétní student zapsán.

V tomto případě by tedy vaše schéma tabulky mělo zahrnovat všechny podrobnosti o studentovi odpovídající danému kurzu, jako je název kurzu, číslo studenta, jméno studenta atd.

Výše uvedený diagram ukazuje jednu tabulku obsluhující dotaz, protože jeden student je namapován přesně na jeden kurz.

CREATE TABLE Student_Course (
    Student_rollno int PRIMARY KEY,
    Student_name text,
    Course_name text
);

Protože Student_rollno je klíč oddílu, vyhledávání podle čísla role přečte přesně jeden oddíl.

Zvládání vztahu jeden k mnoha Cassandra

Jeden až mnoho vztahů znamená mít mezi dvěma tabulkami jednu až mnoho korespondence.

Například kurz může studovat mnoho studentů. Chci vyhledat všechny studenty, kteří studují konkrétní kurz.

Takže dotazem na název kurzu budu mít mnoho jmen studentů, kteří budou studovat konkrétní kurz.

Zde se název kurzu stává klíčem oddílu, takže každý student v kurzu skončí ve stejném oddílu, a číslo řádku se stává sloupcem shlukování, takže každý student zůstává samostatným řádkem.

CREATE TABLE Student_Course (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

Pomocí následujícího dotazu mohu vyhledat všechny studenty určitého kurzu.

SELECT * FROM Student_Course WHERE Course_name = 'Course Name';

Zvládání vztahů mnoho k mnoha Cassandra

Mnoho až mnoho vztahů znamená mít mnoho až mnoho korespondence mezi dvěma tabulkami.

Například kurz může studovat mnoho studentů a student může studovat také mnoho předmětů.

Chci vyhledat všechny studenty, kteří studují konkrétní kurz. Také chci prohledat všechny kurzy, které konkrétní student studuje.

Takže v tomto případě budu mít dvě tabulky, tj. problém rozdělím na dva případy. Toto je nejjasnější ilustrace pravidla duplikace: stejná fakta jsou zapsána dvakrát, takže každý dotaz čte jeden oddíl.

Nejprve vytvořím tabulku, ve které najdete kurzy konkrétního studenta.

CREATE TABLE Student_Course (
    Student_rollno int,
    Course_name text,
    Student_name text,
    PRIMARY KEY (Student_rollno, Course_name)
);

Všechny kurzy konkrétního studenta najdu podle následujícího dotazu.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

Za druhé vytvořím tabulku, pomocí které zjistíte, kolik studentů studuje konkrétní kurz.

CREATE TABLE Course_Student (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

Pomocí následujícího dotazu mohu najít studenta v konkrétním kurzu.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Do obou tabulek se musí zapisovat vždy, když se student připojí ke kurzu, obvykle v rámci jedné zaznamenané dávky, aby obě kopie zůstaly v kroku.

Společný Cassandra Chyby v modelování dat

Většina špatných schémat opakuje stejnou hrstku chyb a každé tracvrací se k zvyku přenesenému z relačního designu.

• Neohraničené oddíly: Výběrem klíče oddílu, například názvu země, se do jednoho oddílu vloží miliony řádků. Pro udržení rozumné velikosti oddílů přidejte časový interval, například (země, měsíc).
• Klíče s velmi nízkou kardinalitou: Klíč oddílu s pouze několika možnými hodnotami, například stavovým příznakem, soustředí veškerý provoz na několik uzlů a zbytek ponechá nečinný.
• Použití POVOLENÍ FILTROVÁNÍ k zajištění fungování dotazu: Prohledá každý oddíl a skryje problém s modelováním. Pokud to dotaz potřebuje, schéma potřebuje další tabulku.
• Modelování entit místo dotazů: Vytvoření tabulky pro studenty a tabulky pro kurzy a následný pokus o jejich propojení v aplikaci maří účel návrhu.
• Časté mazání a přepisování: Každé odstranění zapíše neplatný objekt, který je nutné přečíst a přeskakovat, dokud jej neodstraní zhuštění, což zpomaluje čtení na aktivních oddílech.

Vyhýbání se těmto prvkům udržuje schéma v souladu s pravidly uvedenými v horní části této stránky a s relačními kontrasty shrnutými níže.

Rozdíl mezi RDBMS a Cassandra Datové modelování

Tato schématická rozhodnutí se v praxi uplatňují v Cassandra tabulka a klíčový prostor konzultace.

Nejčastější dotazy