#dotnext, просмотр в записи.
B-Tree индексы в PostgreSQL.
Доклад получился крайне полезным: в связной легкодоступной форме пересказали то, что я в общем-то знал по устройству внутрянки BTree индексов.
Кроме того, в процессе доклада всплыла ещё масса полезностей, которые ускользнули от моего внимания ранее;
1. explain (analyze, costs off, buffers) - синтаксис для просмотра плана запроса с прогнозом числа чтений страниц. Heap fetches - тот самый прогноз походов в таблицу после сканирования индекса для проверки наличия записи в таблице (если она ещё не зачищена от мусора вакуумом).
2. Спикер заострил внимание на разнице index scan и index only scan в плане выполнения запросов (последний не полезет читать доп информацию из таблицы после выполнения, ему для выполнения хватит инфы их индекса).
3. Спикер рассмотрел разницу по работе с BTree индексом в случае индексирования по bigint и по uuid. bigint при добавлении растит индекс в одну сторону. uuid - растит хаотично, расходует больше оперативной памяти в процессе работы. Разница по быстродействию может доходить до 7 раз. Отчасти проблему решает использование uiid v7, в котором используется временная метка. Но это не про стандартную библиотеку c#:)
4. Удаленные из таблицы данные остаются какое-то время залипать в индексе и накручивают Heap fetches в плане выполнения запроса. Помогает не дожидаться долго и тяжёлого вакуума (процесс очистки от мусора) фича из PostgreSQL 14 - bottom-up deletion - зачистка индекса от мусора в процессе вставки новых данных.
5. Спикер упомянул интересный путь оптимизации запросов: учитывать сортировку в индексе и идти к результату с определенной стороны с помощью CTE, например вызовом рекурсивного подзапроса > treshold_value, с постепенным нарастанием treshold_value.
#postgresql
#conf
B-Tree индексы в PostgreSQL.
Доклад получился крайне полезным: в связной легкодоступной форме пересказали то, что я в общем-то знал по устройству внутрянки BTree индексов.
Кроме того, в процессе доклада всплыла ещё масса полезностей, которые ускользнули от моего внимания ранее;
1. explain (analyze, costs off, buffers) - синтаксис для просмотра плана запроса с прогнозом числа чтений страниц. Heap fetches - тот самый прогноз походов в таблицу после сканирования индекса для проверки наличия записи в таблице (если она ещё не зачищена от мусора вакуумом).
2. Спикер заострил внимание на разнице index scan и index only scan в плане выполнения запросов (последний не полезет читать доп информацию из таблицы после выполнения, ему для выполнения хватит инфы их индекса).
3. Спикер рассмотрел разницу по работе с BTree индексом в случае индексирования по bigint и по uuid. bigint при добавлении растит индекс в одну сторону. uuid - растит хаотично, расходует больше оперативной памяти в процессе работы. Разница по быстродействию может доходить до 7 раз. Отчасти проблему решает использование uiid v7, в котором используется временная метка. Но это не про стандартную библиотеку c#:)
4. Удаленные из таблицы данные остаются какое-то время залипать в индексе и накручивают Heap fetches в плане выполнения запроса. Помогает не дожидаться долго и тяжёлого вакуума (процесс очистки от мусора) фича из PostgreSQL 14 - bottom-up deletion - зачистка индекса от мусора в процессе вставки новых данных.
5. Спикер упомянул интересный путь оптимизации запросов: учитывать сортировку в индексе и идти к результату с определенной стороны с помощью CTE, например вызовом рекурсивного подзапроса > treshold_value, с постепенным нарастанием treshold_value.
#postgresql
#conf
🔥1
Был в начале декабря на конференции Highload++ (да, только сейчас нашлось время оформить интересное услышанное в посты). Дальше посты будут под тегом #highload
Услышал ещё некоторые занятные вещи про постгресс.
Ситуация: таблица со счётчиками остатков товара на складе. На 100 строк, постоянно обновляется. При обновлении создаётся копия строки и хранится в блоке рядом с актуальной. В какой-то момент место в блоке кончается - приходится добавлять новую запись в индекс. В итоге под нагрузкой индекс забивается всяким мусором. Решение - индекс с датой последнего изменения, вычитывать последнее значение.
Есть у таблицы есть параметр vacuum_truncate. Разрешает вакууму освободить хвостик таблицы и отдать место ОС. Но есть нюанс - вакуум получает эксклюзивную блокировку таблицы на время пока он проверяет, что во всем кэше бд нет этих блоков и отдает их ОС. А если кэш бд - гигабайты - это может занимать минуты.
pg_stat_replication - посмотреть что происходит в репликации, какой из трёх занятых в ней процессов (отправка WAL по сети, прием WAL и складирование на диск, чтение и применение изменений к реплике) тормозит.
В постгресе 15+ prefetch при репликации по факту не используется, лучше отключить.
#postgresql
#conf
Услышал ещё некоторые занятные вещи про постгресс.
Ситуация: таблица со счётчиками остатков товара на складе. На 100 строк, постоянно обновляется. При обновлении создаётся копия строки и хранится в блоке рядом с актуальной. В какой-то момент место в блоке кончается - приходится добавлять новую запись в индекс. В итоге под нагрузкой индекс забивается всяким мусором. Решение - индекс с датой последнего изменения, вычитывать последнее значение.
Есть у таблицы есть параметр vacuum_truncate. Разрешает вакууму освободить хвостик таблицы и отдать место ОС. Но есть нюанс - вакуум получает эксклюзивную блокировку таблицы на время пока он проверяет, что во всем кэше бд нет этих блоков и отдает их ОС. А если кэш бд - гигабайты - это может занимать минуты.
pg_stat_replication - посмотреть что происходит в репликации, какой из трёх занятых в ней процессов (отправка WAL по сети, прием WAL и складирование на диск, чтение и применение изменений к реплике) тормозит.
В постгресе 15+ prefetch при репликации по факту не используется, лучше отключить.
#postgresql
#conf
👍3🔥1
Продолжаю конспект интересных выступлений с конференции #highload
В Авито в качестве архитектурного паттерна используется "микросервисный ад", больше 4000 микросервисов. В итоге, чтобы понимать происходящее, они трассируют все запросы, а затем отправляют их в графовую базу neo4j, чтобы визуализировать все связи микросервисов и найти закономерности.
Ищут циклические запросы, слишком большую глубину запросов, последовательные вызовы одних и тех же методов, места где ошибки связи с другими сервисами не критичны.
Нашли несколько колец, когда запрос через 3-4 микросервиса вызывает сам себя и в итоге всё отваливается по тайм-ауту.
А самый глубокий запрос выстроился в цепочку длиной в 51 (!) микросервис, через http.
#conf
#highload
В Авито в качестве архитектурного паттерна используется "микросервисный ад", больше 4000 микросервисов. В итоге, чтобы понимать происходящее, они трассируют все запросы, а затем отправляют их в графовую базу neo4j, чтобы визуализировать все связи микросервисов и найти закономерности.
Ищут циклические запросы, слишком большую глубину запросов, последовательные вызовы одних и тех же методов, места где ошибки связи с другими сервисами не критичны.
Нашли несколько колец, когда запрос через 3-4 микросервиса вызывает сам себя и в итоге всё отваливается по тайм-ауту.
А самый глубокий запрос выстроился в цепочку длиной в 51 (!) микросервис, через http.
#conf
#highload
😱6😁2💩1🤣1
Продолжаю конспект интересных выступлений на #highload.
Услышал про интересный способ отпила куска от монолита. Я участвовал только в такой методике: изучаем код монолита, рядом строим микросервис по мотивам, потом долго и мучительно вычерпываем баги.
Спикер от hh рассказал об успешном применении другого подхода:
1. Монолит рефакторится так, чтобы выносимый в микросервис кусок был вынесен в отдельный модуль.
2. Модуль выносится в отдельный проект или пакет, одной строкой подключаемый в монолит.
3. Монолит начинает ходить в функционал будущего микросервиса сам к себе (!) по http.
4. После того, как убедились что все ок, модуль подключается в пустой проект, а в монолите меняется одна строка в конфигурации и он начинает ходить в микросервис.
#conf
#highload
Услышал про интересный способ отпила куска от монолита. Я участвовал только в такой методике: изучаем код монолита, рядом строим микросервис по мотивам, потом долго и мучительно вычерпываем баги.
Спикер от hh рассказал об успешном применении другого подхода:
1. Монолит рефакторится так, чтобы выносимый в микросервис кусок был вынесен в отдельный модуль.
2. Модуль выносится в отдельный проект или пакет, одной строкой подключаемый в монолит.
3. Монолит начинает ходить в функционал будущего микросервиса сам к себе (!) по http.
4. После того, как убедились что все ок, модуль подключается в пустой проект, а в монолите меняется одна строка в конфигурации и он начинает ходить в микросервис.
#conf
#highload
👍5🥰1
Последний интересный доклад был про подход к описанию архитектуры системы - Enterprise architecture on a page. Спикер был из МТС. Суть доклада следующая - был взять относительно новый подход к описанию архитектуры системы, доработан под нужды МТС, а затем внедрен.
Интересна реакция аудитории: процентов 90 восприняли доклад "это что за бред?" А вот люди, близкие к архитектуре очень заинтересовались. Мне пока не хватает квалификации понять всю глубину идеи, но зачем оно нужно - более менее понятно. Для описания того, о чем вещал спикер просто приложу ссылку на исходную идею, получившую развитие в МТС.
#conf
#highload
P.S. Я сам до конца не проникся, ибо не дорос ещё
Интересна реакция аудитории: процентов 90 восприняли доклад "это что за бред?" А вот люди, близкие к архитектуре очень заинтересовались. Мне пока не хватает квалификации понять всю глубину идеи, но зачем оно нужно - более менее понятно. Для описания того, о чем вещал спикер просто приложу ссылку на исходную идею, получившую развитие в МТС.
#conf
#highload
P.S. Я сам до конца не проникся, ибо не дорос ещё
👍2🔥2