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