Postgres не тормозит — тормозит ваше хранилище: NVMe обгоняет EBS в 9 раз

SQLite + NVMe иногда ощущается как читерство. Если моё главное требование — минимально возможная задержка, я не могу представить, чтобы выбрать что-то другое.

Kestrel (AspNetCore) + SQLite + NVMe на одной машине — вот где, по моему опыту, становится по-настоящему жарко. Представьте обработку целой отправки формы, которая меняет состояние базы данных, за десятки — низкие сотни микросекунд. Общее время обработки любого HTTP-запроса может быть значительно меньше одной миллисекунды. Если среднее процессорное время на запрос — 30 мкс, вы можете приблизиться к полумиллиону запросов в секунду на машине с 16–32 ядрами.

«В былые времена» нам приходилось тщательно планировать нижележащий дисковый массив, чтобы выжать каждую унцию производительности из сервера базы данных.

Думаю, есть поколение разработчиков, которые просто воспринимают большие пулы памяти и SSD как должное; есть ментальный разрыв с тем фактом, что базы данных отображаются на нижележащее хранилище.

Это становится очевидным, как только я поднимаю эту тему в разговоре, и я почти вижу, как у них загорается лампочка (так было при обсуждении партиционирования и шардирования), но они никогда не проводят связь между запросом и тем, что он отображается на какие-то артефакты, лежащие на хранилище.

Недавно перевёл наши инстансы RDS с r8g. на r8gd., что добавляет локальный NVMe, и, кажется, средняя задержка ввода-вывода упала с 1,0 мс до 0,1 мс. На больших запросах это накапливается!

CloudNativePG поддерживает Kubernetes Local Storage как одну из своих основных возможностей [0]

Управление постоянными томами, включая:

Поддержку Local Persistent Volumes с шаблонами PVC.

Переиспользование хранилища Persistent Volumes в Pod'ах.

Отдельные тома для WAL-файлов и табличных пространств.

Глава Temporary PostgreSQL Cluster Degradation [1] описывает, как это настроить, и начинается так:

> Хотя стандартный подход обеспечивает надёжность сервиса и использует возможности самовосстановления Kubernetes, есть сценарии, когда работа с временно деградировавшим кластером может быть приемлемой. Это особенно актуально для кластеров PostgreSQL, полагающихся на локальное хранилище узла, где хранилище находится локально на рабочем узле Kubernetes, на котором работает база данных PostgreSQL. Локальное хранилище узла, или просто локальное хранилище, применяется для повышения производительности.

[0] https://cloudnative-pg.io/docs/devel/#main-features

[1] https://cloudnative-pg.io/docs/devel/kubernetes_upgrade/#tem...

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

С репликацией на уровне приложения вы можете амортизировать её до нескольких шагов (например, при коммите выполнить 2PC).

Очевидно, есть нюансы, особенно если приходится читать с другого узла, но именно поэтому перенос репликации как можно выше по стеку обычно даёт лучшую производительность с базами данных — база данных лучше знает, когда обращаться к сети, чем диск.

Честно говоря, сетевое хранилище имело смысл только с HDD, это смешно — платить 10-кратную цену и по IOPS, и по задержке просто за какую-то «операционную гибкость». Вы получаете гораздо более простую и куда более надёжную архитектуру, если просто придерживаетесь локального NVMe и репликации — не то чтобы вы могли отказаться от одного в (тоже реплицированном) сетевом блочном хранилище...

Я использовал postgres до смешного долго, прежде чем узнал разницу между «index scans» и «index only scans».

Включение нужных столбцов в индекс может кардинально улучшить производительность, потому что postgres не нужно читать случайно расположенный кортеж в исходной таблице.