Кэш строк PostgreSQL в сравнении с shared_buffers
shared_buffers
PostgreSQL содержит страницы базы данных. pg_local_cache отдельно хранит
сериализованные полезные нагрузки целых строк под их полными первичными ключами.
Страница, уже находящаяся в памяти, может устранить чтение из хранилища, но
запрос всё ещё должен сформировать результат из кортежей базы данных. Попадание в
кэш строк может вернуть сохранённую полезную нагрузку после проверок допустимости
и снимка.
Операционная система также может кэшировать содержимое файлов. В качестве базовой линии используйте прогретую базу данных.
Кэширует ли PostgreSQL результаты SELECT?
shared_buffers кэширует страницы, используемые запросом, а не его итоговый
набор результатов. Подготовленный оператор
повторно использует работу разбора и может повторно использовать план, но
PostgreSQL всё равно его выполняет. pg_local_cache добавляет кэширование целых
строк через явные вызовы mget; он не кэширует произвольные результаты SELECT и
не переписывает существующие запросы. В примере Node.js
показаны оба API чтения рядом.
Сравнивайте работу, а не только среду хранения
| Чтение | Оставшаяся работа |
|---|---|
| Подготовленный SQL по первичному ключу через прогретые страницы | Обработка протокола, выполнение плана, проверки видимости строк и преобразование результата |
| Попадание в кэш SQL mget | Обработка протокола, выполнение SQL-функции, преобразование ключей, синхронизация кэша, проверки снимка и возврат сохранённой полезной нагрузки |
| Промах или обход SQL mget | Проверки функции плюс запрос к исходной таблице; успешное подходящее заполнение может записать данные в кэш |
Попадание в кэш строк устраняет повторное выполнение запроса к исходной таблице и сериализацию целой строки. Проверки кэша и синхронизация тоже потребляют CPU, а попадание по-прежнему использует соединение и backend PostgreSQL. Этот SQL API не устраняет ограничения соединений или очереди пула соединений.
Учтите затраты
Кэшированная строка занимает дополнительную общую память, даже если её исходная страница уже находится в памяти. Расширение также поддерживает состояние сопоставления и инвалидации. Обновления подключённых таблиц выполняют триггеры расширения. Когда рабочий набор превышает ёмкость, кажущаяся оптимизация чтения может превратиться главным образом в накладные расходы на промахи и вытеснение.
Демонстрация по умолчанию намеренно сравнивает горячий набор из 128 строк с 1 024 слотами кэша, а затем первый проход по 4 096 строкам. В руководстве по бенчмаркам объяснены оба случая, а записи подключённых таблиц измеряются отдельно.
Когда приложение лучше оставить как есть
Сохраняйте существующий запрос, если его сквозная задержка уже приемлема, если приложению нужна лишь небольшая проекция большой строки или если доминируют соединения, диапазоны и агрегация. Сначала сравните обычный пакетный запрос с текущими вызовами по одному ключу в приложении. Выигрыш от пакетной обработки не доказывает выигрыш от кэширования.
pg_local_cache 2.0 требует явных вызовов mget, установки расширения и preload
при запуске. Оно отклоняет таблицы с RLS, секционированием и наследованием.
Кэш строк или внешний кэш?
Для данных, авторитетным источником которых остаётся PostgreSQL, эта схема оставляет инвалидацию на пути записи в базу и не требует поддерживать протокол cache-aside в приложении. Она не предоставляет общую семантику Redis. Необязательная конечная точка RESP2 имеет ограниченный набор команд и отдельную модель безопасности.
Кэш строк PostgreSQL не заменяет состояние приложения с TTL, pub/sub или распределённую координацию. См. технический контракт и примеры транзакций.
Обновлено .