CockroachDB

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 19:48, 17 января 2019.
CockroachDB
CockroachDB logo.png
Разработчики: Cockroach Labs
Выпущена: 18 December 2015 (2015-12-18)
Постоянный выпуск: 2.1.0 / October 1, 2018 (2018-10-01)[Источник 1]
Состояние разработки: Active
Написана на: Go
Операционная система: Кросс-платформенное
Размер дистрибутива: 62MB
Лицензия: Apache License 2.0
Веб-сайт cockroachlabs.com

CockroachDB - это распределенная транзакционная база данных SQL [Источник 2], построенная на строго согласованном хранилище ключей и значений. Она масштабируется горизонтально, устойчива к сбоям диска, компьютера, стойки и даже ЦОДа с минимальными задержками и без непосредственного вмешательства специалиста, поддерживает строго согласованные транзакции ACID.Разработчики CockroachDB предоставляют понятный API SQL для структурирования, управления и запроса данных.

Обзор

Основные преимущества

В настоящее время Cockroach имеет ряд преимуществ над конкурентами:

  • CockroachDB упрощает процесс запуска распределенной базы данных за счет автоматического масштабирования, перебалансировки и восстановления данных[Источник 3];
  • Возможность использования CockroachDB с Kubernetes;
  • CockroachDB позволяет вносить изменения "на лету" без простоев;
  • Распределенные транзакции ACID. Поэтому вы всегда получите правильный ответ, даже если кластер охватывает центры обработки данных или поставщиков облачных услуг;
  • Чтобы оптимизировать отказоустойчивость и производительность, мы предоставляем мощные инструменты для управления жизнью данных клиентов даже на рекордном уровне;
  • Поддержка "классического" синтаксиса postgreSQL;
  • Распределение запросов по кластеру для ускорения транзакционных рабочих нагрузкок даже в огромных запросах данных.

Архитектура

CockroachDB был разработан как open-source проект. Главная концепция, которую вложили разработчики в проект заключается в создании продукта, которым бы сами хотели пользоваться разработчики: масштабируемого и согласованного.

Стоит сказать, что для использования CockroachDB определенно не нужно понимать базовую архитектуру. Данный пункт написан для энтузиастов баз данных для объяснения того, что происходит под капотом.

CockroachDB запускается на машинах с двумя командами:

  • cockroach startс --join флагом для всех начальных узлов в кластере, поэтому процесс знает все другие машины, с которыми он может взаимодействовать;
  • cockroach init выполняет однократную инициализацию кластера;

После того, как Сockroach процесс запущен разработчики взаимодействуют с CockroachDB через SQL API, который смоделирован на основе PostgreSQL. Благодаря симметричному поведению всех узлов можно отправлять SQL-запросы на любой из них; это позволяет CockroachDB действительно легко интегрироваться с балансировщиком нагрузки.

После получения RPC SQL узлы преобразуют их в операции, которые работают с нашим распределенным хранилищем значений ключей. Когда эти RPC начнут заполнять ваш кластер данными, CockroachDB алгоритмически начинает распределять входящие данные между узлами, разбивая данные на куски по 64 МБ, которые называют диапазонами. Каждый диапазон реплицируется как минимум на 3 узла для обеспечения живучести. Таким образом, если узлы выйдут из строя, у вас останутся копии данных, которые можно использовать для чтения и записи, а также для репликации данных на другие узлы.

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

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

В конечном счете, данные записываются и читаются с диска с использованием эффективного механизма хранения, который способен отслеживать временную метку данных. Это обеспечивает преимущество, позволяя поддерживать стандартное SQL AS OF SYSTEM TIME и находить предыдущие данные за определенный период времени.

Недостатки

Cockroach Labs является достаточно открытой компанией, и в отличие от многих не боится публиковать и собирать текущие ошибки и слабые места у себя в документации [Источник 4]

CDC

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

Ниже приведены ограничения в выпуске v2.1, которые будут устранены в будущем:

  • Механизм изменений ядра CockroachDB не готов к внешнему тестированию;
  • Каналы изменений работают только для таблиц с одним семейством столбцов (устанавливается по умолчанию для новых таблиц);
  • Многие запросы DDL (в том числе TRUNCATE и DROP TABLE) вызовут ошибки при подаче изменений при просмотре данных таблиц. В таких случаях нужно начинать новую подачу изменений;
  • Поведение подачи изменений при большинстве типов сбоев еще не настроено;
  • Каналы изменений используют data-pull модель, но в будущем будут использовать модель data-push, что значительно снизит задержки;

Пользовательский интерфейс администратора может стать недоступным для защищенных кластеров

Для доступа к интерфейсу администратора для безопасного кластера теперь требуется информация для входа (например, имя пользователя и пароль). Эта информация для входа в систему хранится в системной таблице, которая реплицируется, как и другие данные в кластере. В случае, если большинство узлов с репликами данных системной таблицы выйдет из строя, пользователи будут заблокированы из интерфейса администратора.

Большие индексные ключи могут ухудшить производительность

Использование таблиц с очень большими первичными или вторичными индексными ключами (> 32 КБ) может привести к чрезмерному использованию памяти. В частности, если первичный или вторичный индексный ключ больше 32 КБ, схема индексации по умолчанию для RocksDB SSTables выходит из строя и приводит к чрезмерно большому индексу. Индекс закреплен в памяти по умолчанию для производительности. Разработчики приводят рекомендацию ограничить размер первичного и вторичного ключей до 4 КБ.

Несущественные недостатки

Несерьезный недостаток, который собирает в себе все глупые баги и недоработки админ-панели, которые наглядно воплощаются в представленной далее баге.

Рисунок 1 - Бонусный недостаток

Для многоядерных систем процент использования ЦП пользователя может превышать 100%. Полное использование одного ядра рассматривается как загрузка процессора на 100%. Если у вас n ядер, то процент ЦП пользователя может варьироваться от 0% (указывает на бездействующую систему) до ( n * 100)% (указывает на полное использование).

Приступая к работе

Установка

Спсобы установки:

Менеджер пакетов Homebrew (только Mac OS)

Для начала (если не установлен) необходимо установить с официального сайта | Homebrew. Далее в терминале:

$ brew install cockroach

Binary (Linux/Mac OS/Windows)

  • Для пользователей Linux/Mac OS

Необходимо загрузить архив CockroachDB для вашей OS(Linux/Mac OS) и извлечь двочиный файл, который далее скопируем в свой PATH

$ wget -qO- https://binaries.cockroachdb.com/cockroach-v2.0.6.linux-amd64.tgz | tar  xvz
$ cp -i cockroach-v2.0.6.linux-amd64/cockroach /usr/local/bin

В случае ошибки используйте префикс sudo.

  • Для пользователей Windows:

Необходимо вручную скачать и разархивировать | CockroachDB v2.0.6 archive for Windows. Далее в командной строке:

PS C:\cockroach-v2.0.6.windows-6.2-amd64> .\cockroach.exe version

Docker (Linux/Mac OS/Windows)

Запуск такого приложения как CockroachDB в Docker, более сложен и подвержен ошибкам чем предыдущие способы. Если у вас нет большого опыта работы с Docker, рекомендуется начать с другого метода установки и развертывания. Итак для начала предполагаем, что у Вас уже стоит последняя версия Docker'a.

  • В случае Linux/Mac OS:
$ sudo docker pull cockroachdb/cockroach:v2.0.6
  • Если же вы пользуетесь Windows:
PS C:\Users\username> docker pull cockroachdb/cockroach:v2.0.6

Запуск локального insecure-кластера

Как только вы установили CockroachDB, вы сразу можете развернуть многоузловой кластер локально.

Шаг 1 - Развернуть первый узел

$ cockroach start --insecure --host=localhost

Эта команда запускает узел в небезопасном режиме, принимая большинство значений по умолчанию для запуска тараканов.

Флаг --insecure делает обмен данными незашифрованным. Поскольку это локальный кластер, --host=localhost указывает узлу прослушивать только localhost, при этом порты по умолчанию используются для внутреннего и клиентского трафика (26257) и для HTTP-запросов из пользовательского интерфейса администратора (8080). Данные узла хранятся в каталоге данных Cockroach.

Шаг 2 - Добавление нескольких node в кластер

С помощью всего лишь одного узла вы уже можете подключить клиент SQL и начать создание базы данных. Однако в реальных условиях всегда требуется, чтобы 3 или более узлов использовали преимущества автоматической репликации, перебалансировки и отказоустойчивости базы данных CockroachDB. Этот шаг помогает имитировать реальное развертывание локально.

В новом терминале добавьте второй узел:

$ cockroach start --insecure --store=node2 --host=localhost --port=26258 --http-port=8081 --join=localhost:26257

В новом терминале добавьте третий узел:

$ cockroach start --insecure --store=node3 --host=localhost --port=26259 --http-port=8082 --join=localhost:26257

Основное различие в этих командах заключается в том, что вы используете флаг --join для подключения новых узлов к кластеру, указав адрес и порт первого узла, в данном случае localhost:26257. Поскольку вы запускаете все узлы на одной и той же машине, вы также устанавливаете флаги --store, --port и --http-port для местоположений и портов, не используемых другими узлами, в реальном же развертывании, каждый узел находится на разных машинах и не все атрибуты необходимы.

Шаг 3 - Проверка кластера

Теперь, когда мы имеем 3 узла, можно использовать любой узел в качестве шлюза SQL в кластер. Чтобы продемонстрировать это, откроем новый терминал и подключим встроенный клиент SQL к узлу 1:

$ cockroach sql --insecure

И выполним некоторые основные операции CockroachDB SQL:

$ CREATE DATABASE bank;
$ CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
$ INSERT INTO bank.accounts VALUES (1, 1000.50);
$ SELECT * FROM bank.accounts;

В ответ получим:

+----+---------+
| id | balance |
+----+---------+
|  1 |  1000.5 |
+----+---------+
(1 row)

Выйдем из SQL-клиента:

$ \q

Далее подключим оболочку SQL к узлу 2, на этот раз указав порт, отличный от порта по умолчанию:

$ cockroach sql --insecure --port=26258

В реальном развертывании все узлы, скорее всего, будут использовать порт по умолчанию 26257, поэтому флаг --port в том случае не нужно. Теперь выполним тот же запрос SELECT:

SELECT * FROM bank.accounts;

И получим такой же результат:

+----+---------+
| id | balance |
+----+---------+
|  1 |  1000.5 |
+----+---------+
(1 row)

Как можно заметить, узел 1 и узел 2 повели себя идентично. Закроем SQL-клиент на узле 2:

\q

Шаг 4 - Мониторинг кластера

Доступ к админке для кластера можно получить, перейдя в браузере http://localhost:8080

$ open http://localhost:8080

Как упоминалось ранее, CockroachDB автоматически реплицирует ваши данные.

Рисунок 2 - Репликация в CockroachDB

Чтобы убедиться, что данные, записанные на предыдущем шаге, были успешно реплицированы, прокрутите вниз до графика реплик на узел и наведите указатель мыши на строку:

Рисунок 3 - График реплик

Количество реплик на каждом узле идентично, что указывает на то, что все данные в кластере были реплицированы 3 раза (по умолчанию).

Шаг 5 - Остановка кластера =

После завершения работы с тестовым кластером переключимся на терминал, на котором запущен первый узел, остановим его. На данный момент, 2 узла по-прежнему онлайн, кластер продолжает работать. Чтобы убедиться, что кластер допустил этот "сбой", подключите встроенную оболочку SQL к узлам 2 или 3. Это можно сделать в том же терминале или в новом терминале.

$ cockroach sql --insecure --port=26258
>SELECT * FROM bank.accounts;
+----+---------+
| id | balance |
+----+---------+
|  1 |  1000.5 |
+----+---------+
(1 row)
>\q

Теперь остановим узлы 2 и 3. Примечение: Для узла 3 процесс завершения работы займет больше времени (около минуты) и в конечном итоге принудительно завершит работу узла. Это происходит потому, что при наличии только 1 из 3 узлов большинство реплик недоступны, и поэтому кластер больше не работает. Чтобы ускорить процесс, нажмите CTRL-C/CMND-C во второй раз.

Если перезапуск кластера не планируется, может потребоваться удалить хранилища данных узлов:

$ rm -rf cockroach-data node2 node3

Запуск локального secure-кластера

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

Шаг 0 - Создание сертификатов безопасности

Можно использовать cockroach cert или команды сертификата CockroachDB или команды openssl для генерации сертификатов безопасности. В этом разделе представлены команды сертификата "таракана". Создайте каталог сертификатов и безопасный каталог для ключа CA. Если используется каталог сертификата по умолчанию ('${HOME}/.таракан-certs`), убедитесь, что он пуст.

$ mkdir my-safe-directory

Создание пары ключей CA:

$ cockroach cert create-ca --certs-dir=certs --ca-key=my-safe-directory/ca.key

Создание клиентской пары ключей для пользователя root:

$ cockroach cert create-client root --certs-dir=certs --ca-key=my-safe-directory/ca.key

Создание пары ключей для узлов:

cockroach cert create-node localhost $(hostname) --certs-dir=certs --ca-key=my-safe-directory/ca.key

Первая команда создает новый каталог для сертификатов. Вторая команда создает сертификат центра сертификации (CA) и ключ: ca.crt и ca.key. Третья команда создает сертификат клиента и ключ, в данном случае для пользователя root: client.root.crt и client.root.key. Эти файлы будут использоваться для защиты связи между встроенной оболочкой SQL и кластером (см. Шаг 4). Четвертая команда создает сертификат узла и ключ: node.crt и node.key. Эти файлы будут использоваться для защиты связи между узлами. Как правило, они создаются отдельно для каждого узла, так как каждый узел имеет уникальные адреса; однако в этом случае, поскольку все узлы будут работать локально, необходимо создать только один сертификат узла и ключа.

Шаги 1-5 (см. пункт 2.2)



Источники

  1. Github Releases // Github [2015-2019] URL:https://github.com/cockroachdb/cockroach/releases (дата обращения: 09.10.2018)
  2. СockroachDB Docs // CockroachDB. [2015-2019] URL: https://www.cockroachlabs.com/docs/stable (дата обращения: 09.10.2018).
  3. Знакомство с СУБД CockroachDB // Habr. [2017-2019] URL: https://habr.com/company/flant/blog/327640 (дата обращения: 09.10.2018).
  4. Known Limitations in CockroachDB v2.1 // CockroachDB [2015-2018] URL: https://www.cockroachlabs.com/docs/stable/known-limitations.html#change-data-capture (дата обращения: 26.12.2018).