Когда кэш строк PostgreSQL помогает
База данных может отдавать каждую страницу из памяти и всё равно тратить время на выполнение запросов, проверку видимости и построение результатов. Кэш строк пытается убрать часть этой повторяющейся работы. Он также добавляет обработку ключей, проверки кэша и затраты на сериализацию. Полезный вопрос — становится ли полный запрос приложения дешевле для вашей нагрузки.
pg_local_cache предоставляет явный API local_cache.mget. Обычные запросы
SELECT сохраняют обычный путь выполнения PostgreSQL. Поэтому прогретый кэш
shared_buffers и прогретый кэш строк — разные экспериментальные условия.
Сначала зафиксируйте контракт результата
Сравнивайте одни и те же ключи, столбцы и форму вывода. Если приложению нужны только два столбца, сравнение этой SQL-проекции с сериализованными целыми строками измеряет разную работу. Если вызывающие стороны ожидают дубликаты, порядок входных данных и null для каждого отсутствующего ключа, включайте работу по выравниванию в каждый клиент.
В руководстве по пакетному чтению приведены
базовые варианты ANY и упорядоченного WITH ORDINALITY. Ни один не требует
расширения. Сначала установите SQL-базовую линию, затем добавляйте кэш.
Меняйте за раз один параметр нагрузки
| Эксперимент | Что зафиксировать | Что он показывает |
|---|---|---|
| Повторные прогретые чтения | Ключи, форма результата, соединения | Повторное использование уже заполненных записей |
| Холодные или отсутствующие ключи | Распределение запросов и размер пакета | Затраты исходной таблицы и отрицательного результата |
| Большие пакеты | Общее число запрошенных ключей и форма полезной нагрузки | Выигрыш от сокращения обменов против работы по каждому ключу |
| Конкурентные записи | Соотношение чтений и записей и границы транзакций | Затраты на инвалидацию, повторное заполнение и видимость |
| Более широкие строки | Распределение ключей и размещение клиента | Сериализация, передача и обход из-за размера строки |
Недопустимое чтение вполне может использовать исходную таблицу. Изучайте
изменения счётчиков вокруг каждого эксперимента; низкая частота попаданий сама
по себе не указывает на сломанную установку. Держите счётчики SQL и RESP
отдельно. В техническом справочнике
описаны local_cache.stats() и local_cache.health().
Используйте общий запускатель и изучайте свидетельства
После quickstart запустите сравнение из репозитория:
./examples/benchmark.sh all > comparison.json
python3 scripts/benchmark_report.py comparison.json
В руководстве по бенчмаркам перечислены требования, управление нагрузкой и метрики. Сохраняйте исходный JSON. Записывайте ревизии расширения и стенда, версию PostgreSQL, машину, число соединений и размещение клиента. Сравнивайте повторные запуски, распределения задержки и использование ресурсов сервера вместе с пропускной способностью. Короткая проверка корректности не является публикуемым результатом скорости.
Принимайте решение на границе приложения
SQL mget и RESP MGET используют разные способы передачи и обработки
результата. Выигрыш одного не доказывает выигрыш другого. В датированных измерениях Go есть случай с одним ключом, где SQL
mget оказался медленнее подготовленного SQL. Это причина проверить, а не
универсальное предсказание.
Оставляйте обычный SQL, если нужны соединения, проекции, блокировки или неподдерживаемые формы таблиц, либо если кэш не даёт измеримой пользы. Для повторных чтений целых строк по первичному ключу проверьте явный API с той же работой клиента, которую фактически выполняет приложение. Продолжите с руководством по выбору кэширования и экспериментом с инвалидацией.