Хотя язык запросов Cassandra похож на язык SQL, их методы моделирования данных совершенно разные.
В Cassandra плохая модель данных может снизить производительность, особенно когда пользователи пытаются реализовать концепции RDBMS на Cassandra. Лучше иметь в виду несколько правил, подробно описанных ниже.
В этом руководстве вы узнаете:
- Правила модели данных Cassandra
- Смоделируйте свои данные в Cassandra
- Отношения один на один
- Работа с отношениями от одного ко многим
- Работа с отношениями "многие ко многим"
Правила модели данных Cassandra
В Кассандре пишет не дорого. Cassandra не поддерживает объединения, группировку по, предложение OR, агрегирование и т. Д. Таким образом, вы должны хранить свои данные таким образом, чтобы их можно было полностью извлечь. Так что эти правила необходимо учитывать при моделировании данных в Cassandra.
- Максимальное количество операций записи
В Кассандре записи очень дешевы. Cassandra оптимизирована для высокой производительности записи. Поэтому постарайтесь максимально увеличить количество операций записи для повышения производительности чтения и доступности данных. Существует компромисс между записью и чтением данных. Итак, оптимизируйте производительность чтения данных за счет максимального увеличения количества записываемых данных.
- Максимальное дублирование данных
Денормализация и дублирование данных - это де-факто Cassandra. Дисковое пространство не дороже памяти, процессора и операций ввода-вывода. Поскольку Cassandra является распределенной базой данных, дублирование данных обеспечивает мгновенную доступность данных и отсутствие единой точки отказа.
Цели моделирования данных
При моделировании данных в Cassandra у вас должны быть следующие цели.
- Равномерное распространение данных по кластеру
Вам нужно равное количество данных на каждом узле кластера Cassandra. Данные распределяются по разным узлам на основе ключей раздела, которые являются первой частью первичного ключа. Итак, попробуйте выбрать целые числа в качестве первичного ключа для равномерного распределения данных по кластеру.
- Сведите к минимуму количество разделов, считываемых при запросе данных
Разделы - это группа записей с одинаковым ключом раздела. Когда выдается запрос на чтение, он собирает данные с разных узлов из разных разделов.
Если разделов будет много, то для сбора данных запроса необходимо посетить все эти разделы.
Это не значит, что разделы не должны создаваться. Если ваши данные очень большие, вы не можете хранить такой огромный объем данных в одном разделе. Одиночный раздел будет замедлен.
Поэтому постарайтесь выбрать сбалансированное количество разделов.
Хороший первичный ключ
Давайте возьмем пример и выясним, какой первичный ключ подходит.
Вот таблица MusicPlaylist.
Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key(SongId, SongName));
В приведенном выше примере таблица MusicPlaylist,
- Songid - это ключ раздела, а
- SongName - столбец кластеризации
- Данные будут сгруппированы на основе SongName. Будет создан только один раздел с SongId. В таблице MusicPlaylist не будет другого раздела.
Эта модель данных будет медленно извлекать данные из-за неправильного первичного ключа.
Вот еще одна таблица MusicPlaylist.
Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key((SongId, Year), SongName));
В приведенном выше примере таблица MusicPlaylist,
- Songid и Year - ключ раздела, а
- SongName - столбец кластеризации.
- Данные будут сгруппированы на основе SongName. В этой таблице каждый год будет создаваться новый раздел. Все песни года будут на одном узле. Этот первичный ключ будет очень полезен для данных.
Благодаря этой модели данных наш поиск данных будет быстрым.
Смоделируйте свои данные в Cassandra
При моделировании запросов следует иметь в виду следующее.
- Определите, какие запросы вы хотите поддерживать
- Присоединяется
- Группа по
- Фильтрация по столбцу и т. Д.
- Создайте таблицу в соответствии с вашими запросами
Создайте таблицу в соответствии с вашими запросами. Создайте таблицу, которая удовлетворит ваши запросы. Попробуйте создать таблицу таким образом, чтобы было прочитано минимальное количество разделов.
Прежде всего, определите, какие запросы вы хотите.
Например, вам нужно?
Отношения один на один
Отношение один к одному означает, что две таблицы имеют соответствие один к одному. Например, студент может зарегистрировать только один курс, и я хочу найти студента, на курс которого зарегистрирован конкретный студент.
Таким образом, в этом случае ваша схема таблицы должна охватывать все детали студента в соответствии с этим конкретным курсом, такие как название курса, номер студента, имя студента и т. Д.
Create table Student_Course(Student rollno int primary key,Student_name text,Course_name text,);
Работа с отношениями от одного ко многим
Отношения «один ко многим» означают наличие соответствия «один ко многим» между двумя таблицами.
Например, курс могут изучать многие студенты. Я хочу найти всех студентов, изучающих определенный курс.
Таким образом, запросив название курса, я получу имена многих студентов, которые будут изучать конкретный курс.
Create table Student_Course(Student_rollno int,Student_name text,Course_name text,);
Я могу получить всех студентов определенного курса с помощью следующего запроса.
Select * from Student_Course where Course_name='Course Name';
Работа с отношениями "многие ко многим"
Отношения «многие ко многим» означают наличие соответствия «многие ко многим» между двумя таблицами.
Например, курс могут изучать многие студенты, а студент также может изучать множество курсов.
Я хочу найти всех студентов, изучающих определенный курс. Кроме того, я хочу найти все курсы, которые изучает конкретный студент.
В этом случае у меня будет две таблицы, т.е. разделить проблему на два случая.
Сначала я создам таблицу, по которой вы сможете найти курсы конкретного студента.
Create table Student_Course(Student_rollno int primary key,Student_name text,Course_name text,);
Я могу найти все курсы конкретного студента по следующему запросу. ->
Select * from Student_Course where student_rollno=rollno;
Во-вторых, я создам таблицу, по которой вы сможете узнать, сколько студентов изучают конкретный курс.
Create table Course_Student(Course_name text primary key,Student_name text,student_rollno int);
Я могу найти студента определенного курса по следующему запросу.
Select * from Course_Student where Course_name=CourseName;
Разница между СУБД и моделированием данных Cassandra
СУБД |
Кассандра |
Хранит данные в нормализованном виде |
Хранит данные в денормализованном виде |
Устаревшие базы данных; структурированные данные |
Широкий рядный магазин, Dynamic; структурированные и неструктурированные данные |
Резюме
Моделирование данных в Cassandra отличается от других СУБД. Моделирование данных Cassandra имеет некоторые правила. Эти правила необходимо соблюдать для хорошего моделирования данных. Помимо этих правил, мы рассмотрели три различных случая моделирования данных и способы их решения.