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

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, обратитесь к документации 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 быстрее, но несколько менее устойчив к отказам.