Масштабирование OLTP при помощи шардинга


#1

Меня интересует вопрос: можно ли отмасштабировать OLTP-нагрузку путем добавления новых серверов при том, что нужно сохранить свойства ACID.
Решил проверить путем сравнения TPS на тесте pgbench. С одной стороны имею базу со scale factor = 300 на одном сервере:
pgbench -i -s 300
С другой стороны, развернул связку fdw+partitioning на трех нодах для той же базы (т.е. на каждом сервере лежит один фрагмент размером примерно в 1/3 от общего). Партиционирование выполнено методом хеширования (в pgbench в 2019 г. появились замечательные параметры --partitions и --partition-method). Каждая нода ссылается на фрагменты с других нод через механизм Foreign Table.
Тестирование выполняю следующим способом:
Для одной ноды - “pgbench … -c N -j N --select-only -n”
Для трехнодовой конфигурации скрипт:
pgbench … -c <N/3> -j <N/3> --select-only -n &
pgbench … -c <N/3> -j <N/3> --select-only -n &
pgbench … -c <N/3> -j <N/3> --select-only -n &

Получаю:

  • При N=10, TPS = 100k (single node) =24k (суммарно с трех нод)
  • N=100, TPS=425k (single node), =75k (fdw)
  • N = 300, TPS=250k и =60k
    Использую --select-only, поскольку в pgbench останавливает тестирование при наличии распределенных дедлоков.
    explain analyze для запроса “SELECT * FROM pgbench_accounts WHERE aid = ;” указывает на причину:
    Planning Time = 0.8 ms, Execution Time = 0.5 ms (если нужно сходить по fdw на другую ноду).
    Planning Time = 0.2 ms, Execution Time = 0.06 ms (если запрос можно выполнить локально).

Получается, это приговор для масштабирования OLTP при помощи FDW, или есть какие-то способы улучшить ситуацию?