Работа с внешней базой данных Cassandra

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

Развертывание высокопроизводительного внешнего экземпляра Cassandra

По умолчанию сервер SberMobile настраивает встроенную службу Cassandra, применяя параметры databaseCassandra* из собственной конфигурации(server.xml по умолчанию) и некоторые жестко закодированные значения.

Чтобы настроить высокопроизводительный экземпляр Cassandra, используйте внешний YAML-файл конфигурации cassandra.yaml. Текущий файл является стандартным способом конфигурирования автономной установки БД Cassandra. Все поддерживаемые параметры описаны в официальной документации по Cassandra.

Чтобы использовать эту функцию:

  1. Установлено Java 8 или JDK 8.

  2. Установите (распакуйте) последнюю версию Cassandra.

  3. Редактировать config/cassandra.yaml

    • Изменение каталога данных и каталога commitlog (желательно на разных физических дисках).

    • Укажите IP-адрес сервера Cassandra в семенах, listen_address и rpc_address.

    • Измените start_rpc на true.

  4. Установите переменную окружения JAVA_HOME в корневую папку JRE/JDK.

  5. Установите переменную окружения CASSANDRA_HOME в папку установки Cassandra.

  6. Отредактируйте bin/cassandra

    • Измените настройки Xms и Xmx на более высокое значение, оставив не менее 2-4 Гб оперативной памяти для операционной системы.

  7. Запустите bin/cassandra и убедитесь в том, что Cassandra начала прослушивание входящих соединений.

  8. Включите опцию "Использовать внешний YAML-файл конфигурации" на вкладке База данных страницы Конфигурация сервера и перезагрузите сервер.

После перезапуска сервер будет использовать внешний файл cassandra.yaml и игнорировать все параметры databaseCassandra* в собственной конфигурации(server.xml по умолчанию). Обратите внимание, что такое переключение может вызвать проблемы с существующей базой данных. Например, если cassandra.yaml содержит другое значение параметра cluster_name, сервер вообще не запустится.

Обычно не следует менять имя кластера. Однако если это неизбежно, вы можете добавить следующие опции JVM в файл ag_server.vmoptions (или другой соответствующий файл):
-Dcassandra.ignore_rack=true
-Dcassandra.ignore_dc=true
Это предотвратит сбой сервера при запуске с другим именем кластера.

Также обратите внимание, что имя и расположение файла cassandra.yaml не настраиваются. Файл должен находиться в домашней (установочной) директории сервера. Файл предоставляется в составе установочного пакета сервера и, в отличие от server.xml, никак не изменяется сервером (т. е. используется только в режиме чтения).

Файл cassandra.yaml в SberMobile представляет собой модифицированную копию файла конфигурации автономной Cassandra по умолчанию. Все модификации дополнены большим заголовком комментария и описанием, как здесь:

########################################################################################################################
#                                               NOTE
########################################################################################################################
# This parameter was changed from default 'true' to 'false' according to internal config
########################################################################################################################

Поскольку изменения в этом файле могут привести к тому, что Cassandra не будет работать или будет работать плохо, дистрибутив SberMobile также содержит резервную копию рабочего файла cassandra.yaml с именем cassandra.default.yaml, в котором сохранены все начальные значения. Этот файл не используется SberMobile и предназначен для использования в качестве точки отката для рабочего файла в случае сбоя.

Оптимизация производительности Cassandra при работе с большими объемами записи

Нагрузка, связанная с записью, подразумевает большое количество операций вставки. Чем быстрее вы вставляете данные, тем быстрее вам нужно их уплотнять, чтобы поддерживать стабильный счетчик. Таким образом, вам нужно отредактировать следующие параметры в cassandra.yaml:

  • Увеличить количество concurrent_compactors.

  • Увеличьте значение compaction_throughput_mb_per_sec или отключите дросселирование, установив этот параметр на ноль.

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

  • уплотнение - предпочтительной стратегией является TimeWindowCompactionStrategy. Она была специально визуализирована для временных рядов и рабочих нагрузок с истекающим TTL. Для ее настройки вам потребуется изменить только compaction_window_unit и compaction_window_size. Также необходимо установить значение true для параметра unchecked_tombstone_compaction, чтобы Cassandra отбрасывала истекшие sstables в режиме реального времени.

  • gc_grace_seconds - должно быть уменьшено или установлено на ноль (только если вы используете одноузловой кластер).

Для изменения параметров уплотнения необходимо выполнить запрос с помощью интерактивного терминала CQL. Запустите bin/cqlsh для подключения к текущему узлу Cassandra:

USE aggregate;
ALTER TABLE <table_name> 
  WITH compaction = {'class' : 'TimeWindowCompactionStrategy', 'compaction_window_unit' : 'HOURS', 'compaction_window_size' : '1', 'unchecked_tombstone_compaction' : 'true'} 
  AND gc_grace_seconds = 0;

Перед настройкой базы данных с использованием перечисленных параметров ознакомьтесь с документацией по Apache Cassandra. В вашем конкретном случае настройка базы данных может отличаться.

Настройки сетевого таймаута

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

Параметр

Описание

range_request_timeout_in_ms

Сколько времени координатор должен ждать завершения сканирования seq или index.

read_request_timeout_in_ms

Сколько времени координатор должен ждать завершения операций чтения.

write_request_timeout_in_ms

Сколько времени координатор должен ждать завершения операций записи.

таймаут_запроса_в_мс

Время ожидания выполнения операций по умолчанию для других, различных операций.

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

Устранение неполадок с помощью Nodetool

nodetool - это встроенный инструмент Cassandra для получения различных сведений об узлах Cassandra. Он может быть чрезвычайно полезен для поиска проблем с производительностью.

Чтобы использовать nodetool со встроенной службой Cassandra SberMobile:

  1. Скачайте установку Cassandra 3.11 и распакуйте ее в любую папку.

  2. Убедитесь, что сервер SberMobile работает со встроенной службой Cassandra.

  3. Убедитесь, что в переменной окружения JAVA_HOME установлена как минимум Java 8 или соответствующий исполняемый файл java находится в переменной PATH. Проверить последнее можно, выполнив команду java -version.

  4. Переходит к извлеченной директории bin/ и выполняет следующую команду:

$ ./nodetool --port 11111 status

Опция --port указывает на встроенный JMX-порт Cassandra. Если вы запускаете nodetool с другой машины, вам также необходимо указать опцию --host с SberMobile IP-адресом или именем хоста.

Вывод команды должен выглядеть следующим образом:

Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  127.0.0.1  1.35 MiB   256          100,0%            38512adb-b868-4ea1-9593-bf3b9950e687  rack1

Основными информационными командами nodetool являются status, version и info. Существует множество других полезных команд, описанных в документации и в самом инструменте (просто запустите его без опций или с помощью команды help ).

Непосредственный запрос с помощью CQLSH

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

Как и nodetool, оболочка также поставляется в составе автономной установки Cassandra.

Чтобы использовать ее с SberMobile встроенной Cassandra:

  1. Скачайте установку Cassandra 3.11 и распакуйте ее в любую папку.

  2. Убедитесь, что на сервере SberMobile запущена встроенная служба Cassandra.

  3. Убедитесь, что Python 2.7 доступен в переменной окружения PATH. Вы можете проверить это, выполнив команду python --version в консоли. Заметим, что Python 3+ не совместим.

  4. Переходит к извлеченной директории bin/ и выполняет следующую команду:

$ ./cqlsh

Текущая команда попытается подключиться к Cassandra, развёрнутой по адресу localhost:9042. При необходимости хост и порт можно указать либо переменными окружения $CQLSH_HOST и $CQLSH_PORT, либо добавив их в саму команду, например, $ ./cqlsh localhost 9042 (обратите внимание, что пара отделяется пробелом, а не двоеточием).

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

$ ./cqlsh -u cassandra -p cassandra

В любом случае вывод должен выглядеть следующим образом:

Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.10-SNAPSHOT | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
WARNING: pyreadline dependency missing.  Install to enable tab completion.
cqlsh>

Чтобы протестировать какой-нибудь запрос, попробуйте сделать следующее:

cqlsh> select count(*) from aggregate.ag_events;

Более подробную информацию о cqlsh можно найти на текущей странице документации. Синтаксис языка CQL описан здесь.