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

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

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

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

rethinkdb --server-tag data_center_1

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

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

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

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

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

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

rethinkdb proxy --join hostname:29015

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

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

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

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

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

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

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

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

Примечание: В настоящее время 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 быстрее, но немного менее устойчив к сбоям.