Выбор стратегии шардирования

Sharded PostgreSQL — это система для горизонтального масштабирования PostgreSQL с помощью шардирования. Использование шардированной системы оправдано в следующих случаях:

• база данных на начальном этапе будет занимать 2 ТБ и более;
• пишущая нагрузка на начальном этапе превысит 5 тысяч записей в секунду (write RPS);
• рост нагрузки и объема данных превысит ресурсы одного узла PostgreSQL менее чем за 10 лет.

Выбор стратегии шардирования зависит от структуры данных:

• Используйте range-стратегию, если данные и запросы имеют естественную или логическую группировку по времени, географическим регионам или диапазонам ID. Эта стратегия позволяет проводить перебалансировку данных и является предпочтительной в большинстве случаев.
• Используйте hash-стратегию, если данные не имеют естественной или логической группировки или необходимо, чтобы на начальном этапе данные распределялись по шардам равномерно.

Для изменения стратегии после запуска системы требуется перераспределить данные по шардам, поэтому перед запуском рекомендуется проверить выбранную стратегию.

Проверка стратегии шардированияПроверка стратегии шардирования

Sharded PostgreSQL поддерживает Shadow Mode (запись и воспроизведение нагрузки). В этом режиме роутер перехватывает и записывает все SQL-запросы к нешардированной базе данных. Затем запросы воспроизводятся на тестовой шардированной базе, что позволяет:

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

Требования к архитектуреТребования к архитектуре

При проектировании шардированной системы соблюдайте следующие требования:

• Включайте все столбцы ключа в условия WHERE.

  Исключения из этого правила:

  • Роутер выполняет виртуальные запросы, например:

    SELECT true;
    SELECT pg_is_in_recovery();
    SELECT now()
    

  • Ключ шардирования был передан в транзакции ранее, например:

    BEGIN;
    SET application_name = "smth";
    SELECT * FROM users WHERE id = 123;
    SELECT * FROM taxes;
    COMMIT;
    

  • Выполняется запрос к справочной таблице (reference table), например:

    SELECT * FROM taxes;
    

  • Ключ шардирования передается через виртуальный параметр (хинт), например:

    INSERT INTO test(id, age) VALUES (10, 16) /*__spqr__sharding_key: 30*/;
    

• Индексируйте столбцы ключа для перемещения данных между шардами.

• Не выполняйте JOIN между таблицами, данные которых находятся на разных шардах. Такой JOIN можно заменить одним из способов:

  • применить денормализацию данных;
  • объединить результаты нескольких запросов в приложении;
  • разместить справочные таблицы на каждом шарде;
  • использовать одинаковые ключи шардирования (colocation) для связанных таблиц, чтобы связанные данные находились на одном шарде.

• Выносите аналитику в специализированные хранилища (ClickHouse® или Greenplum®) с помощью Yandex Data Transfer.

Перебалансировка данныхПеребалансировка данных

Для range-стратегии Sharded PostgreSQL позволяет выполнять перебалансировку данных, когда один из диапазонов данных становится «горячим», то есть получает непропорционально высокую нагрузку по сравнению с остальными диапазонами. Перебалансировка выполняется вручную и состоит из следующих этапов:

1. Выявление «горячего» ключа или диапазона ключей, который приводит к неравномерному распределению данных по шардам.
2. Добавление нового шарда в кластер Managed Service for Sharded PostgreSQL.
3. Перемещение данных из «горячего диапазона» на новый шард с помощью команды DISTRIBUTE ... MOVE ... в консоли администратора.

Перебалансировка происходит без остановки работы системы.