Шардированный не значит распределенный: что важно знать, когда PostgreSQL мало

Все знают, что PostgreSQL — очень эффективная СУБД, которая хорошо масштабируется вертикально. Но из-за отсутствия полноценного горизонтального масштабирования производительность PostgreSQL ограничена возможностями одного сервера. Большинство Citus-подобных решений позволяют шардировать базу, но шардированная база не является распределенной и не дает ACID-гарантий на распределенные транзакции. Мнение о распределенных СУБД диаметрально противоположно: считается, что они хорошо масштабируются горизонтально, у них ACID распределенные транзакции, но низкая эффективность в небольших инсталляциях.

При сравнении монолитных и распределенных СУБД часто говорят об архитектуре, но редко приводят конкретные числа, характеризующие производительность. Наш доклад, наоборот, полностью построен на эмпирическом исследовании этого вопроса. Наш подход прост: мы установили PostgreSQL и распределенные СУБД на одинаковые кластеры из трех железных серверов и сравнили, используя популярный бенчмарк TPC-C.

Из-за безграничных возможностей настройки PostgreSQL и отсутствия универсального конфига нам пришлось попробовать разные варианты его настройки. Мы начали с наиболее производительной, но наименее отказоустойчивой конфигурации без Write-Ahead Logging (WAL) и репликации и дошли до гораздо более надежной конфигурации с двумя синхронными репликами. На каждом этапе мы проводили анализ и искали узкие места, чтобы тонко настроить PostgreSQL. Это позволило честно сравнить PostgreSQL с распределенными СУБД: CockroachDB и YDB — и ответить на вопрос, в какой именно момент PostgreSQL становится мало и как с этим быть.