PostgreSQL *

ERROR: index row size… exceeds maximum… for index ...

Повышение производительности PostgreSQL после настройки параметров

• неиспользуемые индексы
• префиксные «клоны»
• timestamp «в середине»
• индексируемый boolean
• массивы в индексе
• NULL-мусор

На глаза попалась не особо позитивное сравнение Java vs GO. Тестирование большим числом пользователей.

Решил проверить, действительно ли так все не радужно с Go.
Забегая вперед скажу, что при кэшировании в памяти и формировании JSON "на лету" удалось получить до 120 000 [#/sec] на 8 физических ядра.

Базовый сценарий GET запроса:

• Если данные найдены в in memory кэше и они валидные, то формируем JSON из структуры
• Если данных в кэше нет, то ищем их в Bolt DB, если находим, то считываем готовый JSON
• Если данных нет в Bolt DB, то запрашиваем их из БД, сохраняем их в in memory кэше
• Данные в in memory кэше накапливаются в буферном канале, после накопления около 10000 элементов они сбрасываются единым save в Bolt DB
• Если данные в БД менялись (update / insert) то через pg_notify передается уведомление и данные в кэше помечаются как невалидные, при следующем обращении они считываются заново из БД

Под катом результаты тестирования, и код тестового стенда GitHub

Update 06.05.2020

Повилась возможность протестировать в облаке Oracle.

• стенд собран на 3 серверах — 8 Core Intel (16 virtual core), 120 Memory (GB), Oracle Linux 7.7
• локальные NVMe диски — 6.4 TB NVMe SSD Storage min 250k IOPS (4k block)
• локальная сеть между серверами — 8.2 Network Bandwidth (Gbps)
• в режиме прямого чтения из PostgreSQL — до 16 000 [get/sec], сoncurrency 1024, медиана 60 [ms]. Кажды Get запрашивает данные из двух таблиц общим размером 360 000 000 строк. Размер JSON 1800 байт.
• в режиме кэширования — до 100 000 — 120 000 [get/sec], сoncurrency 1024, медиана 2 [ms].
• на вставку в PostgreSQL — около 10 000 [insert/sec].
• при масштабировании с 2 до 4 и 8 Core, рост производительности практически линейный.

Релизы

Привет, Хабр!

Я потихоньку перевожу статьи Маркуса Винанда из блога use the index luke.

Первой статьей в цикле был манифест Маркуса о важности использования безофсетной пагинации на ключах. Мы рассмотрели всего один пример, как этот подход работает на практике. В этой и следующих статьях я буду обосновывать такой подход — с графиками и примерами, как все любят.

Предлагаю ознакомиться с расшифровкой доклада Алексей Лесовский из Data Egret "Основы мониторинга PostgreSQL"

В этом докладе Алексей Лесовский расскажет о ключевых моментах постгресовой статистики, что они означают, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге, как их добавить и как интерпретировать. Доклад будет полезен администраторам баз данных, системным администраторам и разработчикам, которым интересен траблшутинг Postgres'а.

WAL-G — простой и эффективный инструмент для резервного копирования PostgreSQL в облака. По своей основной функциональности он является наследником популярного инструмента WAL-E, но переписанным на Go. Но в WAL-G есть одна важная новая особенность — дельта-копии. Дельта-копии WAL-G хранят страницы файлов, изменившиеся с предыдущей версии резервной копии. В WAL-G реализовано довольно много технологий по распараллеливанию бэкапов. WAL-G работает гораздо быстрее чем, WAL-E.

• редкая запись долетит до середины JOIN
• сизифов JOIN массивов
• вредные JOIN и OR
• CTE JOIN CTE

Я из компании Luxoft.
Предлагаю ознакомиться с расшифровкой доклада Андрей Сальников из Data Egret "Инструменты создания бэкапов PostgreSQL" . В конце обновленная сводная таблица по инструментам

Данный доклад посвящен доступным инструментам бэкапирования PostgreSQL. Логические backup, бинарные backup, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные backup, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.

Недавно мы пригласили в эфир "Цинкового прода" Алексея Лесовского из компании Data Egret. Разговор получился интересный и познавательный, поэтому предлагаю вашему вниманию расшифровку этого выпуска. Из-за внушительного объема пришлось разбить текст на части. Если лень ждать продолжения — можно просто послушать аудиоверсию здесь.

Всем привет, это сороковой выпуск подкаста "Цинковый прод", и с нами в студии постоянные ведущие Антон Околелов, Никита Васильченко и Грицак Олег.

Антон: Итак, у нас сегодня гость, Алексей Лесовский. Лёша, представься пожалуйста, кто ты, чем занимаешься и так далее.

Всем привет! Я бэкэнд-разработчик, пишу микросервисы на Java + Spring. Работаю в одной из команд разработки внутренних продуктов в компании Тинькофф.

У нас в команде часто встает вопрос оптимизации запросов в СУБД. Всегда хочется еще чуть-чуть быстрее, но не всегда можно обойтись продуманно выстроенными индексами — приходится искать какие-то обходные пути. Во время одного из таких скитаний по сети в поисках разумных оптимизаций при работе с БД я нашел бесконечно полезный блог Маркуса Винанда, автора книги SQL Performance Explained. Это тот самый редкий вид блогов, в котором можно читать все статьи подряд.

Хочу перевести для вас небольшую статью Маркуса. Ее можно назвать в какой-то степени манифестом, который стремится привлечь внимание к старой, но до сих пор актуальной проблеме производительности операции offset по стандарту SQL.