Apache cassandra

терминологической

Ниже приведено небольшое сравнение между Cassandra и RDBMS world.

пространство ключей: — это контейнерная коллекция семейств столбцов. Вы можете думать об этом какБаза данныхв мире RDBMS.

Семейство столбцов: -Семейство столбцов — это контейнер для упорядоченного набора строк. Каждая строка, в свою очередь, представляет собой упорядоченную коллекцию столбцов. Думайте об этом какСтолв мире RDBMS.

Ряд:-Строка представляет собой набор столбцов упорядоченных столбцов.

Колонка: -Столбец — это коллекция пар ключ / значение.

RowKey: -Первичный ключ называется ключом строки.

Составной первичный ключ: -Первичный ключ состоит из нескольких столбцов. Одна часть этого ключа затем называетсяКлюч разделаи отдохнутьКлюч кластера,

Ключ раздела: -Данные в Кассандре распространяются по узлам. Назначение ключа разделения состоит в том, чтобы идентифицировать узел, в котором сохранена та конкретная строка, о которой запрашивается. Функция, называемаяраздел, используется для вычисления значения хэша ключа раздела во время записи строки. Например,узел 1имеет ключевые значения в диапазоне от1-10,узел 2содержит11-20а такжеузел 3состоит из диапазона21-30, Когда выполняется команда SELECT с предложением WHERE, хеш-значение ключа раздела используется для поиска требуемого узла, когда узел найден, он выбирает данные и возвращает клиенту. Например, запроси предположим, что значение хеша ключа раздела (в данном случае 5) равно 15, это будетузел 2который будет иметь эту строку в наличии. Ниже наглядное представление этого.

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

Так как у меня есть 2 узла, поэтому я установилв,

Проектирование моделей

В СУБД есть средство типа JOIN, и запись не является дешевой, поэтому мы избегаем дублирования, используя внешние ключи в соответствующих таблицах. Это не так в Кассандре. Cassandra — это распределенная система, написание которой обходится дешево, поэтому вы можете де-нормализовать данные там, где это необходимо. Это помогает извлекать данные, которые вы обычно выбираете через соединения. С другой стороны, чтение данных может быть дорогостоящим, поскольку данные распространяются на узлы и извлекаются через ключи раздела. При разработке моделей вы должны иметь в виду следующие цели:

Равномерное распределение данных в кластере:Первичный ключ — это ключ раздела, если он состоит из одного столбца, ключа раздела и ключа кластера в случае составного первичного ключа. Чтобы распределить данные равномерно, вы должны выбрать столбец для PK, который имеет уникальность и, следовательно, может быть распределен по узлам. Вещи какID, имя пользователя,а такжеЭл. адресиметь уникальность и будет полностью использовать кластер узлов. Но если вы используете такие ключи, какПервый фамилия,Поли т. д. тогда будет очень мало вариантов выбора ключей раздела, и, несмотря на наличие сотен узлов, всегда будет использоваться только несколько, что делает раздел толстым и менее производительным.
Минимизируйте количество операций чтения: -Как я уже говорил, чтение стоит дорого. Если вы моделируете таким образом, что один запрос извлекается из нескольких разделов, это замедляет работу системы.

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

Распределение данных

Рассмотрим каким образом данные распределяются в зависимости от ключа по узлам кластера (cluster nodes). Кассандра позволяет задавать стратегию распределения данных. Первая такая стратегия распределяет данные в зависимости от md5 значения ключа — случайный разметчик (random partitioner). Вторая учитывает само битовое представление ключа — порядковый разметчик (byte-ordered partitioner). Первая стратегия, в большинстве своем, даёт больше преимуществ, так как вам не нужно заботиться о равномерном распределение данных между серверами и подобных проблемах. Вторую стратегию используют в редких случаях, например если необходимы интервальные запросы (range scan)

Важно заметить, что выбор этой стратегии производится перед созданием кластера и фактически не может быть изменён без полной перезагрузки данных

Для распределения данных кассандра использует технику, известную как согласованное хеширование (consistent hashing). Этот подход позволяет распределить данные между узлами и сделать так, что при добавлении и удалении нового узла количество пересылаемых данных было небольшим. Для этого каждому узлу ставится в соответствие метка (token), которая разбивает на части множество всех md5 значений ключей. Так как в большинстве случаев используется RandomPartitioner, рассмотрим его. Как я уже говорил, RandomPartitioner вычисляет 128-битный md5 для каждого ключа. Для определения в каких узлах будут храниться данные, просто перебираются все метки узлов от меньшего к большему, и, когда значение метки становится больше, чем значение md5 ключа, то этот узел вместе с некоторым количеством последующих узлов (в порядке меток) выбирается для сохранения. Общее число выбранных узлов должно быть равным уровню репликации (replication factor). Уровень репликации задаётся для каждого пространства ключей и позволяет регулировать избыточность данных (data redundancy).

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

Вот иллюстрация отображающая при помощи встроенной утилиты nodetool кольцо кластера из 6 узлов с равномерно распределенными метками.

2: Настройка кластера

Конфигурационный файл Cassandra хранится в каталоге /etc/cassandra. Этот файл, cassandra.yaml, содержит множество директив и хорошо закомментирован. С его помощью можно настроить кластер.

Отредактируйте следующие директивы:

cluster_name: имя кластера.
-seeds: список IP-адресов серверов, входящих в кластер (разделяются запятыми).
listen_address: IP-адрес, который будт использовать остальные ноды кластера для подключения к этой ноде. По умолчанию – localhost; замените стандартное значение IP-адресом ноды.
rpc_address: IP-адрес для вызовов удаленных процедур (по умолчанию localhost). Если имя хоста сервера настроено правильно, оставьте значение по умолчанию. В противном случае укажите IP сервера или петлевой адрес (127.0.0.1).
endpoint_snitch: имя snitch-а, который сообщает БД Cassandra, как выглядит сеть (по умолчанию SimpleSnitch). На серверах производства рекомендуется использовать GossipingPropertyFileSnitch.
auto_bootstrap: данной директивы нет в конфигурационном файле, её нужно добавить и установить значение false. Это поможет новым нодам автоматически использовать правильные данные. Если вы добавляете ноды в уже существующий кластер, эта директива опциональна. В новом кластере директива обязательна.

Итак, откройте конфигурационный файл в текстовом редакторе:

Найдите в файле следующие директивы и измените их, как показано ниже. Замените your_server_ip IP-адресом текущего сервера. Список директивы – seeds: должен быть одинаковым на всех серверах кластера.

Затем добавьте директиву auto_bootstrap в конец файла:

Завершив редактирование, сохраните и закройте файл.

Примечание: Повторите инструкции данного раздела на всех серверах кластера.

Установка Apache Cassandra

Самый простой способ установить Apache Cassandra в Ubuntu 18.04 — это установить пакет deb из официального репозитория Apache Cassandra.

На момент написания этой статьи последняя версия Apache Cassandra была и требует, чтобы в системе был установлен OpenJDK 8.

Установка Java довольно проста, начните с обновления индекса пакета:

Установите пакет OpenJDK, набрав:

Проверьте установку Java, выполнив следующую команду, которая выведет версию Java:

Вывод должен выглядеть примерно так:

Установите пакет apt-transport-https, необходимый для доступа к хранилищу через HTTPS:

Следующим шагом является добавление хранилища Apache Cassandra.

Импортируйте GPG хранилища, используя следующую команду :

Приведенная выше команда должна вывести что означает, что ключ был успешно импортирован и пакеты из этого хранилища будут считаться доверенными.

Затем добавьте репозиторий Cassandra в систему, выполнив:

После того, как хранилище будет включено, обновите список пакетов и установите последнюю версию Apache Cassandra, введя:

Служба Cassandra автоматически запустится после завершения процесса установки. Вы можете убедиться, что Cassandra запущена, набрав:

Вы должны увидеть что-то похожее на это:

Поздравляем, на данный момент на вашем сервере Ubuntu установлен Apache Cassandra.

Начальная настройка 1

Останавливаем демон кассандры:
root@debian7:~# service cassandra stop

Очищаем данные тестового кластера по умолчанию:
root@debian7:~# rm -rf /var/lib/cassandra/data/system/*

Далее необходимо изменить параметры выделения динамической памяти Java.

Сохраним оригинальный скрипт:
root@debian7:~# mv /etc/cassandra/cassandra-env.sh /etc/cassandra/cassandra-env.sh.original
root@debian7:~# cat /etc/cassandra/cassandra-env.sh.original >/etc/cassandra/cassandra-env.sh

Открываем файл для редактирования:
root@debian7:~# nano /etc/cassandra/cassandra-env.sh

Меняем строчки:MAX_HEAP_SIZE=»1G» HEAP_NEWSIZE=»200M»
сохраняем изменения и выходим.

Следующий этап — определение настроек в основном конфигурационном файле.

Перед внесением изменений скопируем оригинал:
root@debian7:~# mv /etc/cassandra/cassandra.yaml /etc/cassandra/cassandra.yaml.original

Создадим новый файл с таким же содержанием, кроме большинства строк комментариев:
root@debian7:~# cat /etc/cassandra/cassandra.yaml.original | awk ‘/^/’ >/etc/cassandra/cassandra.yaml

Открываем файл для редактирования:
root@debian7:~# nano /etc/cassandra/cassandra.yaml

Задаем имя кластера:cluster_name: ‘testcluster’

Адрес для прослушивания (укажите адрес узла, на котором производите настройку):listen_address: 192.168.1.81

Apache Cassandra 3.11 Installation on Ubuntu 18.04 LTS Bionic Beaver

Apache Cassandra — это бесплатная база данных NoSQL с открытым исходным кодом, без единой точки отказа. Он обеспечивает линейную масштабируемость и высокую доступность без ущерба для производительности. Apache Cassandra используется рядом организаций, включая Apple, NetFlix, eBay и Easou.

В этом уроке мы покажем вам, как установить Apache Cassandra в Ubuntu 18.04. Те же инструкции применимы для Ubuntu 16.04 и любого дистрибутива на основе Ubuntu, включая Linux Mint, Kubuntu и Elementary OS.

Предпосылки

Чтобы иметь возможность устанавливать пакеты в вашей системе Ubuntu, вы должны войти в систему как пользователь с привилегиями sudo.

Установка Apache Cassandra

Установка Java довольно проста, начните с обновления индекса пакета:

Установите пакет OpenJDK, набрав:

Проверьте установку Java, выполнив следующую команду, которая выведет версию Java:

Вывод должен выглядеть примерно так:

Установите пакет apt-transport-https, необходимый для доступа к хранилищу через HTTPS:

Следующим шагом является добавление хранилища Apache Cassandra.

Импортируйте GPG хранилища, используя следующую команду :

Затем добавьте репозиторий Cassandra в систему, выполнив:

Вы должны увидеть что-то похожее на это:

Поздравляем, на данный момент на вашем сервере Ubuntu установлен Apache Cassandra.

Настройка Apache Cassandra

Данные Apache Cassandra хранятся в каталоге , файлы конфигурации находятся в а параметры запуска Java можно настроить в .

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

Для взаимодействия с Cassandra через CQL (язык запросов Cassandra) вы можете использовать утилиту командной строки с именем которая поставляется с пакетом Cassandra.

Переименование кластера Apache Cassandra

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

Войдите в CQL-терминал Cassandra с помощью :

Выполните следующую команду, чтобы изменить имя кластера на «Linuxize Cluster»:

Измените «Linuxize Cluster» на желаемое имя. После завершения введите для выхода из консоли.

Отредактируйте файл конфигурации и введите имя нового кластера.

/etc/cassandra/cassandra.yaml

Выполните следующую команду, чтобы очистить системный кеш:

Наконец перезапустите сервис Cassandra:

Вывод

Вы успешно установили Apache Cassandra на Ubuntu 18.04. Теперь вы можете посетить официальную страницу документации Apache Cassandra и узнать, как начать работу с Cassandra.

база данных Java Cassandra Ubuntu

Apache Cassandra — это база данных NoSQL с открытым исходным кодом без единой точки отказа, обеспечивающая линейную масштабируемость и высокую доступность без ущерба для производительности. В этом руководстве рассказывается, как установить Apache Cassandra в CentOS 7.

Apache Cassandra — это бесплатная база данных NoSQL с открытым исходным кодом, без единой точки отказа. В этой статье мы расскажем, как установить Apache Cassandra на Debian 10, Buster.

Apache Cassandra — это бесплатная база данных NoSQL с открытым исходным кодом, без единой точки отказа. Из этого туториала Вы узнаете, как установить Apache Cassandra в Debian 9.

Уплотнение

В определенный момент времени данные в колоночном семействе перезапишутся — придут колонки, которые будут иметь те же имя и ключ. То есть, возникнет ситуация, когда в более старой сохранённой таблице и более новой будут содержаться старые и новые данные. Для того, чтобы гарантировать целостность, кассандра обязана читать все эти сохранённые таблицы и выбирать данные с последней меткой времени. Получается, что количество операций позиционирования жёсткого диска при чтении пропорционально количеству сохранённых таблиц. Поэтому для того, чтобы освободить перезаписанные данные и уменьшить количество сохранённых таблиц, существует процесс уплотнения (compaction). Он читает последовательно несколько сохранённых таблиц и записывает новую сохранённую таблицу, в которой объединены данные по меткам времени. Когда таблица полностью записана и введена в использование, кассандра может освободить таблицы-источники(таблицами, которые её образовали). Таким образом, если таблицы содержали перезаписанные данные, то эта избыточность устраняется. Понятно, что во время такой операции объем избыточности увеличивается — новая сохранённая таблица существует на диске вместе с таблицами-источниками, а это значит, что объем места на диске всегда должен быть такой, чтобы можно было произвести уплотнение.

Установка Apache Cassandra кластера в Unix/Linux

Данная СУБД, дает возможность создавать линейную масштабируемость ( если объём данных растет). Для хранения данных, Cassandra юзает ColumnFamily. Данная можель отличается от memcachedb (которые хранят данные только в связке ключ/значение). Cassandra относится к категории хранилищ, повышенно устойчивых к сбоям: помещённые в БД данные автоматически реплицируются на несколько узлов распредёленной сети или даже равномерно распределяются в нескольких дата-центрах. Когда выходит нода из строя, ее функционал подхватывают другие. Добавление новых узлов в кластер и обновление версии Cassandra производится на лету, без дополнительного ручного вмешательства и переконфигурации других узлов. Для упрощения взаимодействия с БД поддерживается язык формирования структурированных запросов CQL (Cassandra Query Language).

Недавно, я описывал простую установку Apache Cassandra в Unix/Linux (для одной ноды):

Пришло время описать установку для нескольких нод с Apache Cassandra, которые представляют собой кластер.

Использование политики повторных подключений Cassandra

Azure Cosmos DB — это система управления ресурсами. Это означает, что в данную секунду можно выполнять определенное количество операций на основе единиц запроса, потребляемых операциями. Если приложение превысит этот лимит в течение данной секунды, запросы будут ограничены по скорости, и будут выданы исключения. API Cassandra в Azure Cosmos DB преобразует эти исключения в ошибки перегрузки в собственном протоколе Cassandra. Чтобы приложение могло перехватывать и повторять запросы в случае ограничения скорости, предусмотрены расширения spark и Java. См. также примеры кода Java для драйверов Datastax версии и для подключения к API Cassandra в Azure Cosmos DB. Если вы используете другие пакеты SDK для доступа к API Cassandra в Azure Cosmos DB, создайте политику подключения для повторения этих исключений.

Команды CQL

Azure Cosmos DB поддерживает следующие команды базы данных для учетных записей API Cassandra.

Get-Help	Поддерживаются:
ALLOW FILTERING	Да
ALTER KEYSPACE	Н/д (служба PaaS, внутреннее управление репликацией)
ALTER MATERIALIZED VIEW	Нет
ALTER_ROLE	Нет
ALTER TABLE	Да
ALTER TYPE	Нет
ALTER USER	Нет
BATCH	Да (только в незарегистрированном пакете)
COMPACT STORAGE	Н/д (служба PaaS)
CREATE AGGREGATE	Нет
CREATE CUSTOM INDEX (SASI)	Нет
CREATE INDEX	Да (без указания имени индекса; индексы в ключах кластеризации или полные замороженные коллекции не поддерживаются)
CREATE FUNCTION	Нет
CREATE KEYSPACE (параметры репликации игнорируются)	Да
CREATE MATERIALIZED VIEW	Нет
CREATE TABLE	Да
CREATE TRIGGER	Нет
CREATE TYPE	Да
CREATE ROLE	Нет
CREATE USER (не рекомендуется во встроенном Cassandra Apache)	Нет
DELETE	Да
DISTINCT	Нет
DROP AGGREGATE	Нет
.DROP FUNCTION	Нет
DROP INDEX	Да
DROP KEYSPACE	Да
DROP MATERIALIZED VIEW	Нет
DROP ROLE	Нет
DROP TABLE	Да
DROP_TRIGGER	Нет
DROP TYPE	Да
DROP USER (не рекомендуется во встроенном Cassandra Apache)	Нет
GRANT	Нет
INSERT	Да
LIST PERMISSIONS	Нет
LIST ROLES	Нет
LIST USERS (не рекомендуется во встроенном Cassandra Apache)	Нет
REVOKE	Нет
SELECT	Да
UPDATE	Да
TRUNCATE	Нет
USE	Да

Expand

This command is used to expand the output. Before using this command, you have to turn the expand command on. Given below is the usage of this command.

cqlsh:tutorialspoint> expand on;
cqlsh:tutorialspoint> select * from emp;

@ Row 1
-----------+------------
    emp_id | 1
  emp_city | Hyderabad
  emp_name | ram
 emp_phone | 9848022338
   emp_sal | 50000
  
@ Row 2
-----------+------------
    emp_id | 2
  emp_city | Delhi
  emp_name | robin
 emp_phone | 9848022339
   emp_sal | 50000
  
@ Row 3
-----------+------------
    emp_id | 4
  emp_city | Pune
  emp_name | rajeev
 emp_phone | 9848022331
   emp_sal | 30000
  
@ Row 4
-----------+------------
    emp_id | 3
  emp_city | Chennai
  emp_name | rahman
 emp_phone | 9848022330
   emp_sal | 50000
(4 rows)

Note − You can turn the expand option off using the following command.

cqlsh:tutorialspoint> expand off;
Disabled Expanded output.

Настройка Apache Cassandra кластера в Unix/Linux

Имеется следующие данные о серверах:

192.168.13.163 — Apache_Cassandra_01 (centos 6)
192.168.13.145 — Apache_Cassandra_02 (kali linux 2)
192.168.13.147 — Apache_Cassandra_03 (Debian

Далее редактируем конфиги на каждой их нод.

-===НОДА_1===-

Редактируем конфиги на нодах будущего кластера на 192.168.13.163:

# vim /etc/cassandra/conf/cassandra.yaml

В данном конфиги нужно изменить (прописать) следующее:

cluster_name — Имя кластера
```
cluster_name: 'cassandra_cluster'
```
seeds — Прописываем адреса нод кластера
```
seeds: "192.168.13.163, 192.168.13.145, 192.168.13.147"
```
listen_address — адрес самой ноды
```
listen_address: 192.168.13.163
```
rpc_address — адрес самой ноды
```
rpc_address: 192.168.13.163
```

Выполняем настройку следующего файла:

# vim /etc/cassandra/conf/cassandra-topology.properties

И прописываем в него:

# Cassandra Node IP=Data Center:Rack
192.168.13.163=dc1:rac1
192.168.13.145=dc1:rac1
192.168.13.147=dc1:rac1


# default for unknown nodes
default=DC1:r1

И переходим к другим нодам.

-===НОДА_2===-

Редактируем конфиги на нодах будущего кластера на 192.168.13.145:

# vim /etc/cassandra/cassandra.yaml

В данном конфиги нужно изменить (прописать) следующее:

cluster_name — Имя кластера
```
cluster_name: 'cassandra_cluster'
```
seeds — Прописываем адреса нод кластера
```
seeds: "192.168.13.163, 192.168.13.145, 192.168.13.147"
```
listen_address — адрес самой ноды
```
listen_address: 192.168.13.145
```
rpc_address — адрес самой ноды
```
rpc_address: 192.168.13.145
```

Выполняем настройку следующего файла:

# vim /etc/cassandra/cassandra-topology.properties

И прописываем в него:

# Cassandra Node IP=Data Center:Rack
192.168.13.163=dc1:rac1
192.168.13.145=dc1:rac1
192.168.13.147=dc1:rac1


# default for unknown nodes
default=DC1:r1

И переходим к другим нодам.

-===НОДА_3===-

Редактируем конфиги на нодах будущего кластера на 192.168.13.147:

# vim /etc/cassandra/cassandra.yaml

В данном конфиги нужно изменить (прописать) следующее:

cluster_name — Имя кластера
```
cluster_name: 'cassandra_cluster'
```
seeds — Прописываем адреса нод кластера
```
seeds: "192.168.13.163, 192.168.13.145, 192.168.13.147"
```
listen_address — адрес самой ноды
```
listen_address: 192.168.13.147
```
rpc_address — адрес самой ноды
```
rpc_address: 192.168.13.147
```

Выполняем настройку следующего файла:

# vim /etc/cassandra/cassandra-topology.properties

И прописываем в него:

# Cassandra Node IP=Data Center:Rack
192.168.13.163=dc1:rac1
192.168.13.145=dc1:rac1
192.168.13.147=dc1:rac1


# default for unknown nodes
default=DC1:r1

И переходим к другим нодам если они имеются.

Модель данных

В терминологии кассандры приложение работает с пространством ключей (keyspace), что соответствует понятию схемы базы данных (database schema) в реляционной модели. В этом пространстве ключей могут находиться несколько колоночных семейств (column family), что соответствует понятию реляционной таблицы. В свою очередь, колоночные семейства содержат колонки (column), которые объединяются при помощи ключа (row key) в записи (row). Колонка состоит из трех частей: имени (column name), метки времени (timestamp) и значения (value). Колонки в пределах записи упорядочены. В отличие от реляционной БД, никаких ограничений на то, чтобы записи (а в терминах БД это строки) содержали колонки с такими же именами как и в других записях — нет. Колоночные семейства могут быть нескольких видов, но в этой статье мы будем опускать эту детализацию. Также в последних версиях кассандры появилась возможность выполнять запросы определения и изменения данных (DDL, DML) при помощи языка CQL, а также создавать вторичные индексы (secondary indices).

С каждым значением связана метка времени — задаваемое пользователем число, которое используется для разрешения конфликтов во время записи: чем больше число, тем колонка считается новее, а при сравнении перетирает старые колонки.

По типам данных: пространство ключей и колоночное семейство — это строки (имена); метка времени — это 64-битное число; а ключ, имя колонки и значение колонки — это массив байтов. Также кассандра имеет понятие типов данных (data type). Эти типы могут по желанию разработчика (опционально) задаваться при создании колоночного семейства. Для имён колонок это называется сравнителем (comparator), для значений и ключей — валидатором (validator). Первый определяет какие байтовые значения допустимы для имён колонок и как их упорядочить. Второй — какие байтовые значение допустимы для значений колонок и ключей. Если эти типы данных не заданы, то кассандра хранит значения и сравнивает их как байтовые строки (BytesType) так как, по сути, они сохраняются внутри.

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

Запись в кассандру работает с большей скоростью, чем чтение. Это меняет подход, который применяется при проектировании. Если рассматривать кассандру с точки зрения проектирования модели данных, то проще представить колоночное семейство не как таблицу, а как материализованное представление (materialized view) — структуру, которая представляет данные некоторого сложного запроса, но хранит их на диске. Вместо того, чтобы пытаться как-либо скомпоновать данные при помощи запросов, лучше постараться сохранить в коночное семейство все, что может понадобиться для этого запроса. То есть, подходить необходимо не со стороны отношений между сущностями или связями между объектами, а со стороны запросов: какие поля требуются выбрать; в каком порядке должны идти записи; какие данные, связанные с основными, должны запрашиваться совместно — всё это должно уже быть сохранено в колоночное семейство. Количество колонок в записи ограничено теоретически 2 миллиардами. Это краткое отступление, а подробней — в статье о техниках проектирования и оптимизации. А теперь давайте углубимся в процесс сохранения данных в кассандру и их чтения.

Кассандра Удалить данные

Команда «Удалить» удаляет всю строку или несколько столбцов из таблицы Student. Когда данные удаляются, они не удаляются из таблицы сразу. Вместо этого удаленные данные помечаются надгробной плитой и удаляются после уплотнения.

Синтаксис

Приведенный выше синтаксис удалит одну или несколько строк в зависимости от фильтрации данных в предложении where.

Приведенный выше синтаксис удалит некоторые столбцы из таблицы.

пример

Вот снимок, который показывает текущее состояние базы данных перед удалением данных.

Вот снимок команды, которая удалит одну строку из таблицы Student.

После успешного выполнения команды «Удалить» одна строка будет удалена из таблицы Student, где значение rollno равно 1.

Вот снимок, который показывает состояние базы данных после удаления данных.

История

Авинаш Лакшман, один из авторов Dynamo от Amazon , и Прашант Малик изначально разработали Cassandra в для поддержки функции поиска по входящим сообщениям Facebook. Facebook выпустил Cassandra как проект с открытым исходным кодом на коде Google в июле 2008 года. В марте 2009 года он стал проектом Apache Incubator . 17 февраля 2010 года вышла на проект топ-уровня.

Разработчики Facebook назвали свою базу данных в честь мифологического троянского пророка Кассандры с классическими намёками на проклятие оракула .

Релизы

Выпуски после окончания включают

0.6, выпущенный 12 апреля 2010 г., добавлена поддержка интегрированного кэширования и Apache Hadoop MapReduce.
0.7, выпущенный 8 января 2011 г., добавлены вторичные индексы и изменения онлайн-схемы.
0.8, выпущенная 2 июня 2011 г., добавлен язык запросов Cassandra (CQL), самонастраивающиеся таблицы памяти и поддержка обновлений с нулевым временем простоя.
1.0, выпущенная 17 октября 2011 г., добавлено интегрированное сжатие, выравнивание сжатия и улучшена производительность чтения.
1.1, выпущенный 23 апреля 2012 г., добавлены самонастраивающиеся кеши, изоляция на уровне строк и поддержка смешанных развертываний SSD и вращающихся дисков.
1.2, выпущенная 2 января 2013 г., добавлена кластеризация виртуальных узлов, межузловая связь, атомарные пакеты и трассировка запросов.
2.0, выпущенный 4 сентября 2013, добавлено легкие операции (на основе Paxos протокола консенсуса), триггера, улучшенные сжатия
2.1 выпущен 10 сентября 2014 г.
2.2 выпущен 20 июля 2015 г.
3.0 выпущен 11 ноября 2015 г.
Выпуски 3.1–3.10 представляли собой ежемесячные выпуски с использованием модели выпуска, подобной тик-таку , причем выпуски с четными номерами предоставляли как новые функции, так и исправления ошибок, в то время как выпуски с нечетными номерами содержали только исправления ошибок.
3.11 выпущен 23 июня 2017 года в виде стабильной серии выпусков 3.11 и исправления ошибок из последнего выпуска функции Tick-tock.
4.0 выпущен 26 июля 2021 г.
4.0.1 выпущена 7 сентября 2021 г.

Версия	Исходная дата выпуска	Последняя версия	Дата выхода	Положение дел
Старая версия, больше не поддерживается: 0,6	2010-04-12	0.6.13	2011-04-18	Больше не поддерживается
Старая версия, больше не поддерживается: 0,7	2011-01-10	0.7.10	2011-10-31	Больше не поддерживается
Старая версия, больше не поддерживается: 0,8	2011-06-03	0.8.10	2012-02-13	Больше не поддерживается
Старая версия, больше не поддерживается: 1.0	2011-10-18	1.0.12	2012-10-04	Больше не поддерживается
Старая версия, больше не поддерживается: 1.1	2012-04-24	1.1.12	2013-05-27	Больше не поддерживается
Старая версия, больше не поддерживается: 1.2	2013-01-02	1.2.19	2014-09-18	Больше не поддерживается
Старая версия, больше не поддерживается: 2.0	2013-09-03	2.0.17	2015-09-21	Больше не поддерживается
Старая версия, больше не поддерживается: 2.1	2014-09-16	2.1.22	2020-08-31	Больше не поддерживается
Старая версия, но все еще поддерживается: 2.2	2015-07-20	2.2.19	2020-11-04	По-прежнему поддерживается, только критические исправления
Старая версия, но все еще поддерживается: 3.0	2015-11-09	3.0.24	2021-02-28	По-прежнему поддерживается
Старая версия, но все еще поддерживается: 3.11	2017-06-23	3.11.10	2021-02-28	По-прежнему поддерживается
Текущая стабильная версия: 4.0	2021-07-26	4.0.1	2021-09-07	Последний релиз
Легенда: Старая версия Старая версия, все еще поддерживается Последняя версия Последняя предварительная версия Будущий выпуск

Согласованность данных

Узлы кластера кассандры равноценны, и клиенты могут соединятся с любым из них, как для записи, так и для чтения. Запросы проходят стадию координации, во время которой, выяснив при помощи ключа и разметчика на каких узлах должны располагаться данные, сервер посылает запросы к этим узлам. Будем называть узел, который выполняет координацию — координатором (coordinator), а узлы, которые выбраны для сохранения записи с данным ключом — узлами-реплик (replica nodes). Физически координатором может быть один из узлов-реплик — это зависит только от ключа, разметчика и меток.

Для каждого запроса, как на чтение, так и на запись, есть возможность задать уровень согласованности данных.

Таким образом, можно регулировать временные задержки операций чтения, записи и настраивать согласованность (tune consistency), а также доступность (availability) каждой из видов операций. По сути, доступность напрямую зависит от уровня согласованности операций чтения и записи, так как он определяет, сколько узлов-реплик может выйти из строя, и при этом эти операции все ещё будут подтверждены.

Если число узлов, с которых приходит подтверждения о записи, в сумме с числом узлов, с которых происходит чтение, больше, чем уровень репликации, то у нас есть гарантия, что после записи новое значение всегда будет прочитано, и это называется строгой согласованностью (strong consistency). При отсутствии строгой согласованности существует возможность того, что операция чтения возвратит устаревшие данные.

В любом случае, значение в конце концов распространится между репликами, но уже после того, как закончится координационное ожидание. Такое распространение называется итоговой согласованностью (eventual consistency). Если не все узлы-реплики будут доступны во время записи, то рано или поздно будут задействованы средства восстановления, такие как чтение с исправлением и анти-энтропийное восстановление узла (anti-entropy node repair). Об этом чуть позже.

Таким образом, при уровне согласованности QUORUM на чтение и на запись всегда будет поддерживаться строгая согласованность, и это будет некий баланс между задержкой операции чтения и записи. При записи ALL, а чтении ONE будет строгая согласованность, и операции чтения будут выполняться быстрее и будут иметь большую доступность, то есть количество вышедших из строя узлов, при котором чтение все еще будет выполнено, может быть большим, чем при QUORUM. Для операций записи же потребуются все рабочие узлы-реплик. При записи ONE, чтении ALL тоже будет строгая согласованность, и операции записи будут выполняться быстрее и доступность записи будет большой, ведь будет достаточно подтвердить лишь, что операция записи прошла хотя бы на одном из серверов, а чтение — медленней и требовать всех узлов-реплик. Если же к приложению нету требования о строгой согласованности, то появляется возможность ускорить и операции чтения и операции записи, а также улучшить доступность за счет выставления меньших уровней согласованности.