Apache Cassandra. Модель данных

Cassandra_logoРеляционные базы данных, в которых основой является табличная структура, подавляющему большинству читателей будут знакомы. Однако если говорить о нетрадиционных концепциях хранения данных, например «ключ-значение», а не таблица, многие с трудом представляют себе о чем идет речь и в каком виде будут храниться данные в этом случае. Я не был исключением.

Имея опыт работы с реляционными СУБД, будь то опыт администрирования или разработки, достаточно трудно сразу переключить мышление на другой характер — изучая нереляционные хранилища все ещё продолжаешь мыслить реляционными понятиями. Для тех, кто ещё полностью не перешел на оперирование нереляционными категориями, я постараюсь описать модель данных СУБД Apache Cassandra — неограниченно масштабируемой нереляционной бесплатной СУБД с открытым исходным кодом.

Описание модели данных начнем с самого простого и дойдем до наивысших по иерархии структур.

Колонка 1 (Column) — наипростейшая единица данных, состоит из трех полей с полезной информацией в теле каждого — имя (Name), значение (Value), метка времени (Timestamp).

column

Метка времени Timestamp необходима для поддержания в актуальном состоянии значения колонки, поскольку теоретически может возникнуть ситуация, когда на разных узлах кластера значения одной и той же колонки будут разными. В таком случае будет использоваться значение колонки, которая имеет самую свежую метку времени, а неактуальные данные на других узлах обновятся.

Запись 2 (Row) — набор колонок с данными. В пределах колоночного семейства уникально идентифицируется ключом записи (Row key), фактически являющимся чем-то вроде первичного ключа.

raw

Записи не дробятся на колонки, а хранятся целиком на определенных узлах. Чтобы понять на каком узле будет храниться запись, используется значение (маркер) хэш-функции от ключа записи — за определенные диапазоны маркеров отвечают определенные узлы в кластере. Этот механизм я подробно расписал в одной 3 из моих статей.

Стоит отметить, что логическое представление записей, рассмотренное выше, может несколько отличаться в различных ситуациях. На это влияет каким образом определен первичный ключ для колоночного семейства. Этой темы, однако, я не планирую касаться, поскольку она подробно рассмотрена в статье Apache Cassandra. Первичные ключи и особенности хранения записей.

Колоночное семейство 4 (Column family) — контейнер для колонок, содержащих полезные данные. В SQL-хранилищах ближайшим аналогом будет таблица.

column family

Как и таблиц, колоночных семейств может быть множество.

Пространство ключей 5 (Keyspace) — аналог схемы 6 базы данных у реляционных СУБД.

keyspaces

Как в любой СУБД может быть множество баз данных, точно также и пространств ключей может быть несколько.

В ближайшем рассмотрении информации выше достаточно, чтобы сформировать определенное представление о модели данных СУБД Cassandra.

comments powered by HyperComments