Рубрика «CQL3»

Cassandra (далее C*) ограничивает WHERE запросы из-за своей внутренней структуры. Эта статья вам покажется сложной, запутанной, если вы не читали первую статью из цикла, где я рассказывал как устроена С*. Прочтите её, пожалуйста, прежде чем приступать к этой.

Цель этой статьи — выступать справочником для C* новичков.

Некоторые отличия CQL от SQL

В SELECT запросах Cassandra Query Language (CQL) отсутсвутют привычные нам SQL операции JOIN, GROUP BY. А операция WHERE сильно урезана. В SQL вы можете фильтровать по любой колонке, тогда как в CQL только по распределительным ключам (partition key), кластерным ключам (clustering columns) и вторичным индексам.

Заметка: В С* 2.0 можно создавать вторичные INDEX-ы у любой колонки наподобие SQL индексов. Фактически же, вторичные индексы Кассандры — это скрытая от вас дополнительная таблица, поэтому производительность WHERE запросов по ним хуже запросов по ключевым колонкам.

Читать полностью »

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

Задача

Допустим у нас есть ad network, который откручивает рекламу. Люди кликают на баннеры, заказчик рекламы платит, мы (сеть), реселлеры (распространители) и хостеры рекламного места имеем на этом доход. Реселлеры рекламного места работают за 20%. Этот процент растёт из-за различных факторов, самое главное, что он не постоянен и новый процент может применяться, например, на клики месячной давности.

Нужно: быстро уметь считать доход каждого реселлера за любой промежуток дней, вести график кликов в режиме реального времени.
Читать полностью »

Статья предназначена для людей пытающихся создать свою первую «таблицу» в БД Cassandra.

За посление несколько релизов Кассандры разработчики взяли правильный вектор направленный на простоту использования этой базы данных. Учитывая её достоинства, такие как скорость работы и отказоустойчиваость, её было сложно как администрировать, так и писать под неё. Сейчас же количество танцев с бубном, которые надо провести прежде чем запустить и начать разрабатывать, свели к минимуму — несколько комманд в bash или один .msi в Windows.
Более того, сильно облегчил жизнь разработчикам недавно обновлённый CQL (язык запросов), вытеснив бинарный и довольно сложный язык Thrift.
Лично я столкнулся с проблемой наличия отсуствия русскоязычных руководств по Кассандре. Самую, на мой взгляд, сложную тему мне бы хотелось поднять в этой статье. Как же дизайнить базу данных то?

  • Статья НЕ предназначена для людей, которые впервые видят слово Cassandra.
  • Статья НЕ служит как рекламный материал той или иной технологии.
  • Статья НЕ стремится доказать что-либо кому-либо.
  • Если скорость записи/чтения не так важна, и если «100% uptime» не сильно нужен, и если у вас всего лишь несколько миллионов записей, то, вероятно, эта статья, да и вся Cassandra в целом, — не то, что вам нужно.

Ликбез

  • Cassandra (далее C*) — распределённая NoSQL БД, поэтому все решения «почему так, а не вот так» всегда принимаются с оглядкой на кластеризацию.
  • CQL — это SQL-подобный язык. Аббревиатура от Cassandra Query Language.
  • Node (нода) — инстанс C*, или java процесс в терминах операционных систем. На одной машине можно запустить несколько нод, например.
  • Основная единица хранения — строка. Строка целиком хранится на нодах, т.е. нет ситуаций когда полстроки — на одной ноде, полстроки — на другой. Строка может динамически раширяться до 2 миллиардов колонок. Это важно.
  • cqlsh — коммандная строка для CQL. Все примеры ниже выполняются именно в ней. Является частью дистрибутива C*.

Основное правило моделирования данных в C*

Кассандра создавалась как распределённая БД с упором на максимальную скорость записи и чтения. Моделировать «таблицы» нужно в зависимости от SELECT запросов вашего приложения.
В SQL мы привыкли накидать таблиц, связей между ними, и потом уже SELECT ... JOIN ... чего хотим и как хотим. Именно JOIN-ы основная проблема с произвоидтельностью в RDBMS. Их нет в CQL.

Первый пример.

У нас есть сотрудники какой-то компании. Создадим таблицу (которые на самом деле называются Column Family, но для простоты перехода с SQL на CQL используют слово table) на CQL и заполним данными:

CREATE TABLE employees (
    name text,
    age int,
    role text,
    PRIMARY KEY (name)
);
INSERT INTO employees (name, age, role) VALUES ('john', 37, 'dev');
INSERT INTO employees (name, age, role) VALUES ('eric', 38, 'ceo');

Таблицы в C* обязаны иметь PRIMARY KEY. Он используется для поиска ноды, в которой хранится искомая строка.

Прочитаем данные:

SELECT * FROM employees;

Эта картинка — руками разукрашенный вывод cqlsh.
Моделирование данных в БД Cassandra 2.0 на CQL3

Выглядит как обычная таблица из реляционной БД. C* создаст две строки.
Моделирование данных в БД Cassandra 2.0 на CQL3
Внимание! Это две внутренние структуры строк, а не таблицы. Если чуть слукавить, то можно сказать, что каждая строка — это как маленькая таблица. Далее понятней.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js