Сравнение структуры Кассандры с реляционными базами данных

Question

Несколько дней назад я читал о хранящемся в широком столбце типе NoSql и исключительно Apache-Cassandra. Я понимаю, что Кассандра состоит из:

Пространство ключей (например, база данных в реляционных базах данных) и поддержка множества семейств столбцов или таблиц (То же, что таблица в реляционных базах данных) и неограниченное количество строк.

Из тегов Stackru:

Широкое хранилище столбцов - это тип базы данных ключ-значение. Он использует таблицы, строки и столбцы, но в отличие от реляционной базы данных, имена и формат столбцов могут варьироваться от строки к строке в одной и той же таблице.

В Cassandra все строки (в таблице) должны иметь ключ строки, тогда каждый ключ строки может иметь несколько столбцов. Я читал о различиях в реализации и хранении данных реляционной базы данных и NoSql (Cassandra) .

Но я не понимаю разницу между структурами:

Представьте себе сценарий, в котором у меня есть таблица (или семейство столбцов в Кассандре):

Когда я выполняю запрос (Cql), как это:

Select * from users;

Это дает мне результат, как вы можете видеть:

lastname | age  | city          | email               
----------+------+---------------+----------------------
      Doe |   36 | Beverly Hills |   [e-mail]       
    Jones |   35 |        Austin |     [e-mail]        
    Byrne |   24 |     San Diego |  [e-mail]         
    Smith |   46 |    Sacramento |   null                      
  Jones2  | null |        Austin |     [e-mail]       

Поэтому я выполняю описанный выше сценарий в реляционной базе данных (MsSql) с запросом удара:

select * from [users] 

И результат:

lastname    age      city              email                    
    Doe     36       Beverly Hills     [e-mail]          
    Jones   35       Austin            [e-mail]             
    Byrne   24       San Diego         [e-mail]         
    Smith   46       Sacramento        NULL                 
   Jones2   NULL     Austin            [e-mail]              

Я знаю, что Cassandra поддерживает динамический столбец, и я могу выполнить это с помощью команды sth:

ALTER TABLE users ADD website varchar;

Но он доступен в реляционной модели, например, в mssql приведенный выше код также может быть реализован. Sth, как:

ALTER TABLE users 
ADD website varchar(MAX) 

Я вижу, что первый результат выбора и второй результат выбора одинаковы. В Cassandra они просто дают ключ строки (фамилию) в качестве отдельного объекта, но это то же самое, что уникальное поле (например, ID или текст) в mssql (и всех реляционных базах данных), и я вижу, что тип столбца в Cassandra является статическим (в моем примере varchar) в отличие от того, что он описывает в теге Stackru.

Итак, мои вопросы:

1. Есть ли в моем воображении недоразумение насчет Кассандры?!

2. Так что же отличается между двумя структурами?! Я показываю вам результат тот же.

3. Существуют ли какие-либо особые сценарии (подобные Json), которые нельзя реализовать в реляционных базах данных, но Cassandra поддерживает?(Например, я знаю, что вложенные столбцы не поддерживают в Cassandra.)

Спасибо за чтение.

Answer 1

Мы должны взглянуть на более сложный пример, чтобы увидеть различия:)

Для начала:

• термин семейства столбцов использовался в старом Thrift API
• в более новом CQL API используется таблица терминов

Таблица определяется как "двумерное представление многомерного семейства столбцов".

Термин "широкие ряды" был связан главным образом с Thrift API. В cql это определяется немного по-другому, но внизу выглядит так же.

Сравнение SQL и CQL. В SQL таблица представляет собой набор строк. В простом примере это выглядит как в CQL это то же самое, но это не так. Таблица CQL - это набор разделов, где каждый раздел может представлять собой одну строку (например, если у вас нет ключа кластеризации) или несколько строк. Раздел, содержащий несколько строк, в терминологии Thrift называется "широкий ряд". Чтобы увидеть, как он хранится, пожалуйста, прочитайте, например, часть о составных ключах здесь.

Есть больше различий:

• CQL может иметь статические столбцы, которые хранятся на уровне раздела - кажется, что каждая строка в разделе имеет общее значение, но на самом деле это одно значение, сохраненное на верхнем уровне. Может использоваться также для моделирования отношений 1:N
• В CQL вы можете иметь столбцы типа коллекции - набор, список, карта
• Столбец может содержать определенный пользователем тип (вы можете определить, например, address как тип, и использовать этот тип во многих местах), или коллекция может быть коллекцией пользовательских типов
• Но также CQL не поддерживает JOIN, которые доступны в SQL, и вы должны очень тщательно структурировать свои таблицы, поскольку они должны строго ориентироваться на запросы (в cassandra вы не можете запрашивать данные по любому значению столбца, вторичные индексы также имеют много ограничения). Обычно говорят, что в реляционной модели вы моделируете таблицы явно на основе данных, тогда как в Кассандре вы моделируете на основе запросов.

Я надеюсь, что смог сделать это немного более понятным для вас. Я рекомендую просмотреть некоторые видео (или прочитать слайды) из Курса основных понятий Datastax в качестве твердого введения в Кассандру.

Answer 2

По моему опыту, CQL вводит в заблуждение многих людей. Прежде всего, вы никогда не захотите сделать:

SELECT * FROM a_table_here;

В производственном кластере Cassandra, поскольку вы кладете огромную нагрузку на ваш узел координатора, чтобы агрегировать все данные со всех других узлов. Также по умолчанию вам будет возвращено максимум 10000 "строк".

Чтобы понять, как Cassandra хранит ваши данные, нам нужно сначала установить несколько терминов:

Существует первичный ключ, в вашем случае "фамилия", он хэшируется, чтобы определить, какому узлу в кластере принадлежит этот диапазон, и он там хранится (плюс любые узлы реплики).

Далее есть столбцы кластера, я не знаю, есть ли у вас в вашем примере, но вы определяете их как ПЕРВИЧНЫЙ КЛЮЧ ((фамилия), возраст, город). В этом примере вы кластеризуетесь по возрасту, а затем по городу, это ЗАКАЗ.

Теперь для упрощенного высокоуровневого просмотра Cassandra для вашего варианта использования, он сохраняет данные в виде карты в упорядоченную мультикарту:

Доу -> 36: Беверли-Хиллз -> [e-mail]

Где "Doe" - это первичный ключ, который сообщает вам, какие узлы имеют эту строку данных. И 36: Беверли-Хиллз - это упорядоченные ключи кластеризации (часть упорядоченного ключа с несколькими картами). И, наконец, [e-mail] - это окончательное значение (может быть несколько) для карты на мультикарте.

Есть много неприятностей, которые я оставил, чтобы сделать пример простым, для более углубленного изучения я настоятельно рекомендую прочитать: http://www.planetcassandra.org/making-the-change-from-thrift-to-cql/