Cassandra Model danych z prostym przykładem bazy danych

Chociaż Cassandra język zapytań przypomina SQL język, ich metody modelowania danych są zupełnie inne.

In Cassandra, zły model danych może obniżyć wydajność, zwłaszcza gdy użytkownicy próbują wdrożyć koncepcje RDBMS Cassandra. Najlepiej jest pamiętać o kilku zasadach opisanych poniżej.

Cassandra Reguły modelu danych

In Cassandra, pisze, że nie są drogie. Cassandra nie obsługuje złączeń, grupowania według, klauzuli OR, agregacji itp. Musisz więc przechowywać swoje dane w taki sposób, aby można je było w całości odzyskać. Dlatego też należy pamiętać o tych zasadach podczas modelowania danych Cassandra.

Zmaksymalizuj liczbę zapisów

In Cassandra, pisze, że są bardzo tanie. Cassandra jest zoptymalizowany pod kątem wysokiej wydajności zapisu. Staraj się więc maksymalizować liczbę zapisów, aby uzyskać lepszą wydajność odczytu i dostępność danych. Istnieje kompromis między zapisem a odczytem danych. Dlatego optymalizuj wydajność odczytu danych, maksymalizując liczbę zapisów.

Maksymalizuj duplikację danych

Denormalizacja i duplikacja danych są de facto zjawiskiem Cassandra. Przestrzeń dyskowa nie jest droższa od pamięci, przetwarzania CPU i operacji IO. Cassandra to rozproszona baza danych, więc duplikacja danych zapewnia natychmiastową dostępność danych i brak pojedynczego punktu awarii.

Cassandra Cele modelowania danych

Podczas modelowania danych w programie należy mieć następujące cele: Cassandra:

Rozłóż dane równomiernie wokół Cluster

Chcesz mieć taką samą ilość danych w każdym węźle Cassandra ClusterDane są rozprowadzane do różnych węzłów na podstawie kluczy partycji, które stanowią pierwszą część klucza podstawowego. Dlatego, aby równomiernie rozprowadzić dane w klastrze, należy wybrać kolumnę o dużej kardynalności jako klucz partycji.

Minimalizuj liczbę partycji odczytywanych podczas odpytywania danych

Partycja to grupa rekordów z tym samym kluczem partycji. Po wydaniu zapytania odczytu zbiera ono dane z różnych węzłów z różnych partycji.

Jeśli będzie wiele partycji, należy odwiedzić wszystkie te partycje w celu zebrania danych zapytania.

Nie oznacza to, że nie należy tworzyć partycji. Jeśli dane są bardzo duże, nie można przechowywać ich na jednej partycji. Pojedyncza partycja będzie wolniejsza.

Spróbuj więc wybrać zrównoważoną liczbę partycji.

Dobry klucz podstawowy Cassandra

Oba powyższe cele sprowadzają się do jednej decyzji, dlatego dwa schematy poniżej pokazują tę samą tabelę z jednym, słabym kluczem, a drugim poprawnym.

Weźmy na przykład i sprawdźmy, który klucz podstawowy jest dobry.

Oto tabela MusicPlaylist.

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

W powyższym przykładzie tabela MusicPlaylist,

• SongId to klucz partycji, a
• SongName to kolumna klastrująca
• Dane zostaną pogrupowane na podstawie nazwy utworu (SongName). Dla każdego identyfikatora utworu (SongId) zostanie utworzona tylko jedna partycja, a ponieważ każdy utwór ma odrębny identyfikator, każda partycja zawiera jeden wiersz.

W tym modelu danych pobieranie danych będzie powolne ze względu na zły klucz podstawowy.

Oto kolejna tabela MusicPlaylist.

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

W powyższym przykładzie tabela MusicPlaylist,

• SongId i Year to klucze partycji, a
• SongName jest kolumną klastrującą.
• Dane zostaną pogrupowane na podstawie SongName. W tej tabeli, każdego roku, zostanie utworzona nowa partycja. Wszystkie piosenki roku będą w tym samym węźle. Ten klucz podstawowy będzie bardzo przydatny dla danych.

Dzięki temu modelowi danych nasze pobieranie danych będzie szybkie.

Modeluj swoje dane w Cassandra

Podczas modelowania zapytań należy pamiętać o następujących kwestiach:

Określ, jakie zapytania chcesz obsługiwać

Przede wszystkim określ, jakich zapytań potrzebujesz.

Na przykład, czy potrzebujesz?

• Łączy
• Grupuj według
• Filtrowanie według której kolumny itp.

Utwórz tabelę zgodnie ze swoimi zapytaniami

Utwórz tabelę zgodnie ze swoimi zapytaniami. Utwórz tabelę, która zaspokoi Twoje zapytania. Spróbuj utworzyć tabelę w taki sposób, aby odczytać minimalną liczbę partycji.

Następne trzy sekcje stosują tę zasadę do trzech typów relacji, które można znaleźć w niemal każdym schemacie.

Obsługa relacji jeden do jednego w Cassandra

Relacja jeden do jednego oznacza, że ​​dwie tabele mają korespondencję jeden do jednego. Przykładowo, student może zapisać się tylko na jeden kurs, a ja chcę wyszukać na nim kurs, na którym dany student jest zarejestrowany.

W tym przypadku schemat tabeli powinien obejmować wszystkie dane studenta odpowiadające danemu kursowi, takie jak nazwa kursu, numer indeksu studenta, imię i nazwisko studenta itp.

Powyższy diagram przedstawia pojedynczą tabelę obsługującą zapytanie, ponieważ każdy student jest przypisany dokładnie do jednego kursu.

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

Ponieważ Student_rollno jest kluczem partycji, wyszukiwanie po numerze rolki odczytuje dokładnie jedną partycję.

Obsługa relacji jeden do wielu w Cassandra

Relacja jeden do wielu oznacza zgodność jeden do wielu między dwiema tabelami.

Na przykład, na danym kursie może uczyć się wielu studentów. Chcę przeszukać wszystkich studentów studiujących dany kierunek.

Zapytanie o nazwę kursu spowoduje wyświetlenie wielu nazwisk studentów, którzy będą studiować dany kurs.

Tutaj nazwa kursu staje się kluczem partycji, dzięki czemu każdy student danego kursu trafia do tej samej partycji, a numer indeksu staje się kolumną klastrowania, dzięki czemu każdy student pozostaje w odrębnym wierszu.

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

Mogę pobrać wszystkich studentów z danego kursu za pomocą następującego zapytania.

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

Obsługa relacji wiele do wielu w Cassandra

Relacje wiele do wielu oznaczają korespondencję wiele do wielu między dwiema tabelami.

Na przykład, na danym kursie może uczyć się wielu studentów, a student może również studiować na wielu kursach.

Chcę przeszukać wszystkich studentów studiujących dany kierunek. Chcę także przeszukać cały kurs, na którym studiuje dany student.

W tym przypadku będę miał dwie tabele, czyli podzielę problem na dwa przypadki. To najwyraźniejsza ilustracja zasady duplikacji: te same fakty są zapisywane dwukrotnie, tak aby każde zapytanie odczytało jedną partycję.

Najpierw utworzę tabelę, w której znajdziesz kursy danego studenta.

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

Mogę znaleźć wszystkie kursy danego studenta za pomocą następującego zapytania.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

Po drugie, stworzę tabelę, dzięki której dowiesz się, ilu studentów studiuje dany kierunek.

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

Mogę znaleźć studenta na konkretnym kursie za pomocą następującego zapytania.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Za każdym razem, gdy student dołącza do kursu, należy dokonać zapisu w obu tabelach. Zazwyczaj odbywa się to w ramach jednego zalogowanego pliku, aby obie kopie tabel były spójne.

wspólny Cassandra Błędy w modelowaniu danych

Większość słabych schematów powtarza tę samą garść błędów, a każdy z nich tracpowraca do nawyku przeniesionego z projektowania relacyjnego.

• Nieograniczone partycje: Wybór klucza partycji, takiego jak nazwa kraju, umieszcza miliony wierszy w jednej partycji. Dodaj przedział czasowy, na przykład (kraj, miesiąc), aby zachować rozsądny rozmiar partycji.
• Klucze o bardzo niskiej kardynalności: Klucz partycji, który może przyjmować tylko kilka wartości, na przykład flagę stanu, koncentruje cały ruch na kilku węzłach, pozostawiając resztę bezczynną.
• Użycie opcji ALLOW FILTERING w celu uruchomienia zapytania: Skanuje każdą partycję i ukrywa problem z modelowaniem. Jeśli zapytanie tego wymaga, schemat wymaga innej tabeli.
• Modelowanie jednostek zamiast zapytań: Utworzenie tabeli studentów i tabeli kursów, a następnie próba połączenia ich w aplikacji mija się z celem projektu.
• Częste usuwanie i nadpisywanie: Każde usunięcie powoduje utworzenie nagrobka, który musi zostać odczytany i pominięty do momentu usunięcia go przez kompaktowanie, co spowalnia odczyt na gorących partycjach.

Unikanie ich pozwala zachować zgodność schematu z zasadami określonymi na górze tej strony oraz z kontrastami relacyjnymi podsumowanymi poniżej.

Różnica między RDBMS i Cassandra Modelowanie danych

Te decyzje schematyczne są stosowane w praktyce w Cassandra stół oraz spacja klawiszowa tutoriale.

FAQ