Масштабирование, фрагментация и репликация

RethinkDB позволяет фрагментировать и реплицировать кластер на основе таблиц. Параметры легко настраиваются через веб-административную консоль. Кроме того, команды ReQL для настройки таблиц позволяют использовать сценарии и более точно управлять репликацией, распределяя реплики отдельных таблиц по заданным группам серверов с помощью тегов серверов.

Настройка многоцентрового окружения

Для группировки серверов в центрах обработки данных RethinkDB использует теги серверов. Серверы могут быть «помечены» одним или несколькими именами групп при запуске:

rethinkdb --server-tag data_center_1

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

Запуск прокси-узла

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

Прокси-узел не хранит данные; он выступает в качестве маршрутизатора запросов. Это обеспечивает некоторые преимущества производительности:

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

Для запуска прокси-узла используйте параметр командной строки proxy при запуске.

rethinkdb proxy --join hostname:29015

Фрагментация и репликация через веб-консоль

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

• Перейдите к представлению таблиц (Таблицы → имя таблицы).
• Нажмите кнопку Перенастроить.
• Установите количество фрагментов и реплик.
• Нажмите кнопку Применить конфигурацию.

Таблица может иметь до 64 фрагментов.

Фрагментация и репликация через ReQL

Существует три основных команды для изменения фрагментации и репликации в ReQL. Кроме того, есть значения более низкого уровня, которые можно изменить, манипулируя таблицами системы.

• Команда table_create (или tableCreate) может указать начальные значения для shards и replicas.
• Команда reconfigure может изменить значения для shards и replicas для существующей таблицы.
• Команда rebalance перебалансирует фрагменты таблиц.

Дополнительную информацию об администрировании через ReQL см. в документации по API для отдельных команд, а также в документации по Инструментам администрирования.

Примечание: В настоящее время RethinkDB использует фрагменты диапазонов, но в будущем планируется переход на фрагменты по хешу. Следите за прогрессом на странице Github issue #364.

Расширенная настройка

Эти задачи нельзя выполнить через веб-интерфейс.

Теги серверов

Все серверы в кластере RethinkDB могут иметь ноль или более тегов, которые могут использоваться в конфигурациях таблиц для сопоставления реплик с серверами, указанными по тегу.

Серверу можно присвоить теги с помощью параметра --server-tag при запуске:

rethinkdb --server-tag us --server-tag us_west

Во время работы конфигурацию сервера можно изменить, записав в rethinkdb.server_config таблицу системы.

# get server by UUID
r.db('rethinkdb').table('server_config').get(
    'd5211b11-9824-47b1-9f2e-516a999a6451').update(
    {tags: ['default', 'us', 'us_west']}).run(conn)

Если при запуске не указаны теги, сервер будет запущен с одним тегом default. Изменение информации о фрагментации/репликации из веб-интерфейса или команд ReQL, которые не указывают теги серверов, повлияет на все серверы с тегом default.

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

Когда серверам присваиваются теги, вы можете использовать их в команде reconfigure. Для назначения 3 реплик таблицы users серверам us_west и 2 серверам us_east:

r.table('users').reconfigure(shards=2, replicas={'us_west':3, 
    'us_east':2}, primary_replica_tag='us_east').run(conn)

Если вы удалите все теги с сервера и затем перенастройте все таблицы кластера, этот сервер будет выведен из строя.

# decommission a server
r.db('rethinkdb').table('server_config').get(
    'd5211b11-9824-47b1-9f2e-516a999a6451').update(
    {tags: []}).run(conn)
r.db('database').reconfigure(shards=2, replicas=3).run(conn)

Обратите внимание, что таблицы настраиваются при создании и при вызове команды reconfigure , но конфигурации не сохраняются сервером в остальных случаях. Для согласованной перенастройки таблиц, особенно если ваша конфигурация использует теги серверов, необходимо сохранить конфигурацию в скрипте. Подробнее об этом см. в разделе Инструменты администрирования.

Подтверждения записей и надежность

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

Параметр подтверждения записи для таблицы определяет, когда кластер подтверждает запрос записи как выполненный. Существует два возможных параметра:

• majority: Кластер отправляет подтверждение, когда большинство реплик подтвердили его. Это значение по умолчанию.
• single: Кластер отправляет подтверждение, когда любая реплика подтвердила его.

Для изменения этих параметров для таблицы:

r.db('rethinkdb').table('table_config').get(
    '31c92680-f70c-4a4b-a49e-b238eb12c023').update(
        {"write_acks": "single"}).run(conn)

Параметр durability для таблицы определяет, когда записи записываются. В режиме hard надежности записи записываются на диск перед отправкой подтверждений; в режиме soft подтверждения отправляются сразу после получения. Режим soft быстрее, но немного менее устойчив к сбоям.