Cassandra Модел на данни с пример за проста база данни

Въпреки че Cassandra езикът за заявки наподобява SQL език, техните методи за моделиране на данни са напълно различни.

In Cassandra, лош модел на данни може да влоши производителността, особено когато потребителите се опитват да внедрят концепциите на RDBMS Cassandra. Най-добре е да имате предвид няколко правила, описани по-долу.

Cassandra Правила за модел на данни

In Cassandra, пише не са скъпи. Cassandra не поддържа присъединяване, групиране по, клауза ИЛИ, агрегиране и т.н. Така че трябва да съхранявате данните си по такъв начин, че да могат да бъдат напълно извличани. Така че тези правила трябва да се имат предвид при моделиране на данни Cassandra.

Увеличете максимално броя на писанията

In Cassandra, пише са много евтини. Cassandra е оптимизиран за висока производителност на запис. Затова се опитайте да увеличите максимално броя на записите си за по-добра производителност на четене и наличност на данни. Има компромис между запис на данни и четене на данни. Затова оптимизирайте производителността на четене на данни, като увеличите максимално броя на записите на данни.

Увеличете дублирането на данни

Денормализацията на данните и дублирането на данни са дефакто Cassandra. Дисковото пространство не е по-скъпо от паметта, обработката на процесора и работата на IO. като Cassandra е разпределена база данни, така че дублирането на данни осигурява незабавна наличност на данни и няма нито една точка на отказ.

Cassandra Цели за моделиране на данни

Трябва да имате следните цели, докато моделирате данни Cassandra:

Разпръснете данните равномерно около Cluster

Искате еднакво количество данни за всеки възел на Cassandra ClusterДанните се разпределят към различни възли въз основа на ключове за дялове, които са първата част на първичния ключ. Затова се опитайте да изберете колона с висока кардиналност като ключ за дялове, за да разпределите данните равномерно в клъстера.

Намалете до минимум броя на прочетените дялове, докато заявявате данни

Дялът е група от записи с един и същ ключ за дял. Когато се издаде заявка за четене, тя събира данни от различни възли от различни дялове.

Ако ще има много дялове, всички тези дялове трябва да бъдат посетени за събиране на данните за заявката.

Това не означава, че не трябва да се създават дялове. Ако данните ви са много големи, не можете да съхранявате това огромно количество данни на един дял. Работата на един дял ще се забави.

Затова се опитайте да изберете балансиран брой дялове.

Добър първичен ключ Cassandra

И двете цели по-горе се свеждат до едно решение, така че двете схеми по-долу показват една и съща таблица с лош ключ и след това с надежден такъв.

Нека вземем пример и да открием кой първичен ключ е добър.

Ето таблицата MusicPlaylist.

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

В горния пример таблицата MusicPlaylist,

• SongId е ключът на дяла и
• SongName е колоната за клъстериране
• Данните ще бъдат клъстерирани въз основа на SongName. Ще бъде създаден само един дял за всеки SongId и тъй като всяка песен има отделен идентификатор, всеки дял съдържа един ред.

Извличането на данни ще бъде бавно от този модел на данни поради лош първичен ключ.

Ето още една таблица MusicPlaylist.

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

В горния пример таблицата MusicPlaylist,

• SongId и Year са ключът на дяла, а
• SongName е колоната за клъстериране.
• Данните ще бъдат групирани въз основа на SongName. В тази таблица всяка година ще се създава нов дял. Всички песни на годината ще бъдат на един и същ възел. Този първичен ключ ще бъде много полезен за данните.

Нашето извличане на данни ще бъде бързо с този модел на данни.

Моделирайте вашите данни Cassandra

Трябва да имате предвид следните неща, докато моделирате вашите заявки:

Определете какви заявки искате да поддържате

Първо, определете какви заявки искате.

Например, имате ли нужда?

• Се присъедини към
• Групирай по
• Филтриране по коя колона и т.н.

Създайте таблица според вашите заявки

Създайте таблица според вашите заявки. Създайте таблица, която ще задоволи вашите запитвания. Опитайте се да създадете таблица по такъв начин, че да трябва да се прочетат минимален брой дялове.

Трите следващи раздела прилагат този принцип към трите типа взаимоотношения, които се срещат в почти всяка схема.

Справяне с взаимоотношения едно към едно в Cassandra

Връзката едно към едно означава, че две таблици имат съответствие едно към едно. Например, студентът може да регистрира само един курс и аз искам да търся за студент, в който курс е регистриран конкретен студент.

Така че в този случай схемата на вашата таблица трябва да включва всички подробности за ученика, съответстващи на този конкретен курс, като името на курса, номер на кандидата, име на ученика и т.н.

Диаграмата по-горе показва една таблица, обслужваща заявката, защото един студент съответства на точно един курс.

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

Тъй като Student_rollno е ключът на дяла, търсенето по номер на ролка чете точно един дял.

Управление на връзката „един към много“. Cassandra

Връзките едно към много означава да има кореспонденция едно към много между две таблици.

Например, един курс може да се изучава от много студенти. Искам да търся всички студенти, които учат определен курс.

Така че чрез запитване за име на курс ще имам много имена на студенти, които ще изучават определен курс.

Тук името на курса става ключ на дяла, така че всеки студент в курса попада в един и същ дял, а номерът на списъка става колона за клъстериране, така че всеки студент остава отделен ред.

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

Мога да извлека всички студенти за определен курс чрез следната заявка.

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

Справяне с много към много взаимоотношения в Cassandra

Много към много връзки означава да има много към много кореспонденция между две таблици.

Например, един курс може да се изучава от много студенти и един студент също може да изучава много курсове.

Искам да търся всички студенти, които учат определен курс. Освен това искам да търся в целия курс, който изучава конкретен студент.

Така че в този случай ще имам две таблици, т.е. ще разделя проблема на два случая. Това е най-ясната илюстрация на правилото за дублиране: едни и същи факти се записват два пъти, така че всяка заявка чете един дял.

Първо, ще създам таблица, чрез която можете да намерите курсове от конкретен студент.

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

Мога да намеря всички курсове от конкретен студент чрез следната заявка.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

Второ, ще създам таблица, чрез която можете да намерите колко студенти учат определен курс.

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

Мога да намеря студент в определен курс чрез следната заявка.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

И в двете таблици трябва да се записва информация всеки път, когато студент се присъедини към курс, обикновено в рамките на един регистриран пакет, така че двете копия да останат в синхрон.

Общ Cassandra Грешки при моделиране на данни

Повечето лоши схеми повтарят едни и същи шепа грешки и всяка от тях tracобратно към навик, пренесен от релационния дизайн.

• Неограничени дялове: Избирането на ключ за дял, като например име на държава, поставя милиони редове в един дял. Добавете времеви интервал, например (държава, месец), за да запазите дяловете в рамките на разумен размер.
• Ключове с много ниска кардиналност: Ключ за дял само с няколко възможни стойности, като например флаг за състояние, концентрира целия трафик върху няколко възела и оставя останалите неактивни.
• Използване на ALLOW FILTERING за работа на заявка: Сканира всеки дял и скрива проблем с моделирането. Ако заявката се нуждае от него, схемата се нуждае от друга таблица.
• Моделиране на обекти вместо заявки: Изграждането на таблица за студенти и таблица за курсове, а след това опитът да се обединят в приложението, обезсмисля целта на дизайна.
• Чести изтривания и презаписвания: Всяко изтриване записва надгробен обект, който трябва да бъде прочетен и пропуснат, докато уплътняването не го премахне, което забавя четенето на горещи дялове.

Избягването им поддържа схемата в съответствие с правилата, посочени в горната част на тази страница, и с релационните контрасти, обобщени по-долу.

Разлика между RDBMS и Cassandra Моделиране на данни

Тези решения по схемата се прилагат на практика в Cassandra маса намлява ключово пространство уроци.

Въпроси и Отговори