Lmst

Recuerden actualizar sus passwords en #postgresql15 -> scram-sha-256 🤖

Looks like #Glom is broken on #Debian because #libgda 5 does support #postgresql15 anymore basically. That should not be too hard to fix even though I need to update #libgdamm as well.

#федичитальня #postgresql #postgresql15

Сортировка по индексу.

#Btree #индексы можно и для сортировки за O(n) использовать без буферизации всех строк где-либо. Но с неопределёнными значениями и порядком сортировки есть нюанс - положение их в индексе задаётся при создании и, если запрашиваемое положение отличается, то индекс не может быть использован.

Вообще странно, что не воткнули костыль для простейших случаев, если nulls не там, просто читаем индекс с другого конца, до тех пор, пока не наткнёмся на не #null, после чего начнём читать индекс так, как изначально и планировалось, до тех пор, пока не на кнёмся на null, который послужит нам эдаким EOF. Сложность чтения бы сохранилась линейной, всего пару переменных и ифников для стейт-контрола добавить. Не думаю, что это был бы значимый оверхед.

#PostgreSQL #федичитальня #postgresql15

Все мои посты здесь собираются в этот гигапост в качестве сохранения от удаления. В бонус - небольшие редактирования, когда через неделю-две читаешь, что написал - диву даёшься, как так можно плохо писать.
https://strizhechenko.github.io/2023/02/18/postgres.html

Заметил в книжке пример о том, что можно делать хитрый WHERE по сочетанию параметров через VALUES и скобочки.

WHERE (x, y) IN (VALUES ('a', 'b'), ('c', 'd'))

Интересно насколько эффективно оно работает в сравнении с пачкой OR? Длина собранного запроса короче, больше шансы уложиться в один TCP PUSH/ACK пакет при средних размерах таких списков, это понятно. Читаемость - хз. А с точки зрения вычислений хз вдвойне. Композитным индексам, наверное, пофигу.

#федичитальня #PostgreSQL #PostgreSQL15 #контрольные_точки #фоновая_запись

За полгода я прочитал треть книжки. За выходные на природе прочитал 30 страниц. Медленно.

Контрольная точка - это две метки в #wal с началом и концом. В начале фиксируется список грязных буферов, в конце - все зафиксированные на момент начала грязные буферы сдамплены на диск. По контрольной точке восстановливается согласованное состояние на момент её начала при восстановлении из резервных копий. Файлы wal, кроме предыдущей завершённой и текущей контрольной точки бесполезны. При достижении `max_wal_size` форсируется _внеплановая_ контрольная точка. Много внеплановых контрольных точек – плохо. С ними вообще любопытно: делаешь часто - лишние накладные расходы, плохо, делаешь редко – плохо, возрастает время восстановления, растёт объём хранимых wal-файлов. Это как менеджер, спрашивающий как дела по задаче. Подстраивать интервалы для checkpointer'а нужно по обратной связи из мониторинга, учитывая профиль нагрузки на систему. Такое себе, я ожидал больше динамики и автоматизации.

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

#Журнал можно записывать синхронно и асинхронно.

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

Асинхронный режим допустим, если вы готовы потерять пару сотен последних транзакций, даже если нужно будет повторить их в ручном режиме или компенсировать убытки из своего кармана. Исправный ИБП, сигнал о потере питания от которого вызывает штатное завершение работы системы, снижает вероятность такой ситуации раз в десять.

У журнала несколько уровней записи - minimal, replica, logical. Как я понял, logical это для master, replica это для slave, minimal это для fucking slaves. Про logical надо бы подробнее почитать, в книжке он мимоходом упоминается. Синхронная репликация журнала, когда коммит записи на мастере означает гарантию чтения этой записи на реплике, звучит как головная боль для администратора БД и тормоза. Мастер-мастер репликация звучит ещё более сложной. Асинхронная репликация журнала _без_ гарантии чтения с реплики выглядит гораздо проще, кажется большинству систем этого за глаза хватать должно.

Видел в https://highload.guide милую схемку с:

- 1 master,
- 1-2 slaves, выделенных для снятия резервных копий,
- N-slaves для readonly OLAP-нагрузки.

Интересно, кстати, как с использованием этого у #mastodon обстоят дела, уж чего-чего, а readonly нагрузки тут достаточно.

Возникшие вопросы, которые пока остаются без ответа

- Как в PostgreSQL выглядит инициализация дополнительной реплики и какую нагрузку это создаёт на master?
- Возможна ли иерархическая репликация для распределения сетевой нагрузки на Master?
- Как себя в таком случае чувствуют промежуточные полумастер-реплики?

#ФедиЧитальня #PostgreSQL15 не совсем из книги, но по той же теме.

Глянул кусочек highload.guide, выцепил хорошую выжимку про классификацию репликаций:

- логическая - работает с кортежами; пример - row based binary log в MySQL; бутылочное горлышко - процессор slave.
- физическая - работает со страницами; примеры - pg_wal, innodb undo-redo; бутылочное горлышко - диск (не совсем понял master'а или slave'а, не совсем понял, а как же буферы; возможно дело в большей степени касается MySQL с несколькими журналами одновременно)
- statement based - сплошная боль, есть места где можно получить неконсистентные данные между master и slave, но в случае условной бигдаты - очень низкие накладные расходы на передачу данных по сети, большой update на всю таблицу прилетит практически одним запросом; разве что выполнять его придётся заново на slave, из-за этого может быть длинный лаг репликации.

Если slave может блокировать удаление журнала master'ом, чтобы догнаться в случае ребута, чем больше отставание, тем больше размер журнала. Если slave вообще не догоняет master в принципе и отставание только нарастает - со временем это закончится забитым дисковым хранилищем.

В PostgreSQL есть Logical Log Streaming Replication, который позволяет не миррорить часть таблиц на slave. Как это применять - я не придумал. В теории можно не хранить на слейвах для актуальных данных архивные данные, что позволит немного сэкономить на дисковом пространстве, особенно если slave'ов много.

P.S:
- Раньше жил в прекрасном мире, где БД находится на том же сервере, где и приложение, ни о какой репликации и не думал.
- Сейчас живу в прекрасном мире, где БД поддерживает отдельная команда, репликация уже готова, хоть и без гарантии синхронных записи на мастер и чтения со слэйва (а я и не против), бери да пользуйся.

Deep dive engineering blog post from Ozan Saka about how we made #PostgreSQL15 support generally available in #AzureCosmosDB for PostgreSQL within just 1 week of the PG 15 release! (Powered by the Citus database extension)

https://devblogs.microsoft.com/cosmosdb/enabling-postgresql-15-in-azure-cosmos-db-for-postgresql-how-we-did-it/