Сравнение структуры Cassandra с реляционными базами данных
несколько дней назад я прочитал о широко-столбцовом типе NoSQL и исключительно Apache-Кассандра. Насколько я понимаю, Кассандра состоит из:--8-->
пространство ключей (например, база данных в реляционных базах данных) и поддержка многих семейств столбцов или таблиц (таких же, как таблица в реляционных базах данных) и неограниченных строк.
из тегов Stackoverflow:
широкое хранилище столбцов-это тип базы данных ключ-значение. Он использует таблицы, строки и столбцы, но в отличие от реляционной базы данных, имена и формат столбцов может меняться от строки к строке в одной таблице.
в Cassandra все строки (в таблице) должны иметь ключ строки, тогда каждый ключ строки может иметь несколько столбцов. Я читал о различиях в реализации и хранении данных реляционной базы данных и NoSql (Cassandra) .
но я не понимаю разницы между структуру :
представьте себе сценарий, в котором у меня есть таблица (или столбца семья в Кассандре):
когда я выполняю запрос (Cql), как это :
Select * from users;
это дает мне результат, как вы можете увидеть :
lastname | age | city | email
----------+------+---------------+----------------------
Doe | 36 | Beverly Hills | janedoe@email.com
Jones | 35 | Austin | bob@example.com
Byrne | 24 | San Diego | robbyrne@email.com
Smith | 46 | Sacramento | null
Jones2 | null | Austin | bob@example.com
поэтому я выполняю приведенный выше сценарий в реляционной базе данных (MsSql) с запросом blow :
select * from [users]
в результате :
lastname age city email
Doe 36 Beverly Hills janedoe@email.com
Jones 35 Austin bob@example.com
Byrne 24 San Diego robbyrne@email.com
Smith 46 Sacramento NULL
Jones2 NULL Austin bob@example.com
Я знаю, что Кассандра поддерживает динамический столбец, и я могу выполнить это, используя sth, как:
ALTER TABLE users ADD website varchar;
но он доступен в реляционной модели для пример в mssql вышеуказанный код также может быть реализован. Sth как :
ALTER TABLE users
ADD website varchar(MAX)
Я вижу, что первый выбор и второй результат выбора одинаковы.
В Cassandra они просто дают ключ строки (lastname) как автономный объект, но он такой же, как уникальное поле (например, ID или текст) в mssql (и всех реляционных базах данных), и я вижу, что тип столбца в Cassandra статичен (в моем примере varchar
) в отличие от того, что он описывает в теге Stackoverflow.
Итак, мои вопросы :
есть ли какое-либо недопонимание в моем воображении о Кассандре?!
так что же отличается между двумя структурами ?! Я покажу вам результат тот же.
есть ли какие-либо специальные сценарии (например, Json), которые не могут быть реализованы в реляционных базах данных, но Cassandra поддерживает ?( Например, я знаю, что вложенный столбец не поддерживает в Cassandra.)
спасибо чтение.
2 ответов
мы должны рассмотреть более сложный пример, чтобы увидеть разницу :)
для начала:
- термин семейства столбцов использовался в более старом API бережливости
- в новом CQL API, используется таблица терминов
таблица определяется как"двумерное представление многомерного семейства столбцов".
термин "широкие строки" был связан в основном с API бережливости. В cql он определен немного по-другому, но под ним выглядит одинаково.
сравнение SQL nad CQL. В SQL таблица представляет собой набор строк. В простом примере это выглядит так, как в CQL это то же самое, но это не так. Таблица CQL-это набор разделов, где каждый раздел может быть только одной строкой (например, если у вас нет ключа кластеризации) или несколькими строками. Раздел, содержащий несколько строк, находится в экономной терминологии с именем "wide-row". Чтобы узнать, как он хранится внизу, прочитайте, например, часть о составных ключах из здесь.
есть больше различий:
- CQL может иметь статические столбцы, которые хранятся на уровне раздела-it кажется, что каждая строка в разделе имеет общее значение, но на самом деле это одно значение, хранящееся на верхнем уровне. Его можно также использовать для моделирования отношений 1:N
- в CQL вы можете иметь столбцы типа коллекции-set, list, map
- столбец может содержать определенный пользователем тип (вы можете определить, например,
address
как тип, и повторно используйте этот тип в много мест), или собрание может быть коллекция пользовательских типов - но также CQL не поддерживает соединения, которые доступны в SQL, и вы должны очень тщательно структурировать свои таблицы, так как они должны будьте строго ориентированы на запрос (в cassandra вы не можете запрашивать данные значение столбца, вторичные индексы также имеют много ограничений). Это обычно говорят, что в реляционной модели вы четко моделируете таблицы на основе по данным, когда в cassandra вы моделируете на основе запросов.
надеюсь, мне удалось сделать это немного более ясным для вас. Я рекомендую смотреть некоторые видео (или читать слайды) из Datastax Основные Понятия Курс как твердое введение в Кассандру.
по моему опыту CQL вводит в заблуждение многих людей. Прежде всего, вы никогда не захотите сделать:
выберите * из a_table_here;
в производственном кластере Cassandra, так как вы накладываете огромную нагрузку на свой узел координатора для агрегирования всех данных со всех других узлов. Также по умолчанию вам будет возвращено максимум 10000 "строк".
чтобы понять, как Кассандра хранит ваши данные, нам нужно сначала установить несколько условий:
есть первичный ключ, в вашем случае "lastname", это хэшируется, чтобы определить, какой узел в кластере владеет этим диапазоном, и он хранится там (плюс любые узлы реплики).
далее есть столбцы кластера, я не знаю, есть ли у вас в вашем примере,но вы определяете их как первичный ключ ((фамилия), возраст, город). В этом примере кластеризации по возрасту первого, то город, это приказал.
теперь для упрощенного представления высокого уровня Кассандры для вашего использования случай, он хранит данные как карта к приказанному Multimap:
Доу - > 36: Беверли-Хиллз - > janedoe@email.com
где " Doe " является первичным ключом, который сообщает вам, какие узлы имеют эту строку данных. И 36: Beverly Hills-это упорядоченные ключи кластеризации (часть упорядоченного ключа multimap). Наконец janedoe@email.com является конечным значением (может быть несколько раз) для карты в Multimap.
есть много нюансов, которые я оставил, чтобы сделать пример простым, для более глубокого я бы настоятельно рекомендовал прочитать:http://www.planetcassandra.org/making-the-change-from-thrift-to-cql/