Был в начале декабря на конференции Highload++ (да, только сейчас нашлось время оформить интересное услышанное в посты). Дальше посты будут под тегом #highload

Услышал ещё некоторые занятные вещи про постгресс.

Ситуация: таблица со счётчиками остатков товара на складе. На 100 строк, постоянно обновляется. При обновлении создаётся копия строки и хранится в блоке рядом с актуальной. В какой-то момент место в блоке кончается - приходится добавлять новую запись в индекс. В итоге под нагрузкой индекс забивается всяким мусором. Решение - индекс с датой последнего изменения, вычитывать последнее значение.

Есть у таблицы есть параметр vacuum_truncate. Разрешает вакууму освободить хвостик таблицы и отдать место ОС. Но есть нюанс - вакуум получает эксклюзивную блокировку таблицы на время пока он проверяет, что во всем кэше бд нет этих блоков и отдает их ОС. А если кэш бд - гигабайты - это может занимать минуты.

pg_stat_replication - посмотреть что происходит в репликации, какой из трёх занятых в ней процессов (отправка WAL по сети, прием WAL и складирование на диск, чтение и применение изменений к реплике) тормозит.

В постгресе 15+ prefetch при репликации по факту не используется, лучше отключить.

#postgresql
#conf

Продолжаю конспект интересных выступлений с конференции #highload

В Авито в качестве архитектурного паттерна используется "микросервисный ад", больше 4000 микросервисов. В итоге, чтобы понимать происходящее, они трассируют все запросы, а затем отправляют их в графовую базу neo4j, чтобы визуализировать все связи микросервисов и найти закономерности.

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

Нашли несколько колец, когда запрос через 3-4 микросервиса вызывает сам себя и в итоге всё отваливается по тайм-ауту.

А самый глубокий запрос выстроился в цепочку длиной в 51 (!) микросервис, через http.

#conf
#highload

Продолжаю конспект интересных выступлений на #highload.

Услышал про интересный способ отпила куска от монолита. Я участвовал только в такой методике: изучаем код монолита, рядом строим микросервис по мотивам, потом долго и мучительно вычерпываем баги.

Спикер от hh рассказал об успешном применении другого подхода:
1. Монолит рефакторится так, чтобы выносимый в микросервис кусок был вынесен в отдельный модуль.
2. Модуль выносится в отдельный проект или пакет, одной строкой подключаемый в монолит.
3. Монолит начинает ходить в функционал будущего микросервиса сам к себе (!) по http.
4. После того, как убедились что все ок, модуль подключается в пустой проект, а в монолите меняется одна строка в конфигурации и он начинает ходить в микросервис.

#conf
#highload

Последний интересный доклад был про подход к описанию архитектуры системы - Enterprise architecture on a page. Спикер был из МТС. Суть доклада следующая - был взять относительно новый подход к описанию архитектуры системы, доработан под нужды МТС, а затем внедрен.

Интересна реакция аудитории: процентов 90 восприняли доклад "это что за бред?" А вот люди, близкие к архитектуре очень заинтересовались. Мне пока не хватает квалификации понять всю глубину идеи, но зачем оно нужно - более менее понятно. Для описания того, о чем вещал спикер просто приложу ссылку на исходную идею, получившую развитие в МТС.

#conf
#highload

P.S. Я сам до конца не проникся, ибо не дорос ещё

Пожалуй пришло время обновить закреплённый пост. Каналу уже 5 лет, с прошлого закрепа изменилось многое.

Датасаенс, питон и наука были заброшены. В настоящий момент я работаю сеньор C# разработчиком в одном из российских банков.

За прошедшие 5 лет я сменил 4 места работы:
1. Фирма, занимающая АСУ ТП в области учёта ресурсов.
2. Медтех стартап в Сколково, делали системы поддержки принятия врачебных решений.
3. Сеть общепита, делал бэкенд службы доставки.
4. Банк, текущее место работы. Работаю в домене клиентских карточек.

Мой технологический стек:
C#, PostgreSQL. Плотно работал с MongoDB, RabbitMQ, Tarantool, умею строить базовую инфраструктуру: логи (Loki), метрики (Prometheus), девопсятина (gitlab, gitea, github actions, docker).

Поверхностно знаком с Apache Kafka, MS SQL и фронтовыми фреймворками - React.js и AvaloniaUI.

По образованию я инженер-оптик, потому часть базы приходится добирать на ходу. В планах закрыть гештальт по алгоритмам и двигаться в сторону архитектуры.

Далее будет навигация по каналу.

Общие теги:
#csharp@eshu_coding - общий тег для постов про разные аспекты разработки на языке программирования c#
#postgresql@eshu_coding - разные интересные моменты про PostgreSQL.
#devops@eshu_coding - мои эксперименты в девопсятине и инфраструктуре.
#mongodb@eshu_coding - записки про MongoDB.
#tarantool@eshu_coding - заметки про Tarantool.

Pet - проекты:
#палантир@eshu_coding - завершенный проект, которым я занимался весь 2021 год - поисковик по телеграму.
#sphagnum@eshu_coding - попытка написать свой брокер сообщений, пока застопорилась на стадии изучения теории и прототипирования по причине нехватки времени.

Книги:
#рихтер@eshu_coding - заметки и конспекты по основополагающей книге про C# - CLR via C#. Программирование на платформе Microsoft .NET Framework 4.5 на языке C#, Джеффри Рихтер. Хоть .NET 4.5 вышел до моего появления в IT, внутренности платформы во основном остались прежними.

Конспекты прослушанных выступлений на конференциях:
#dotnext@eshu_coding - Dotnext 2023
#highload@eshu_coding - Highload++ 2024

Шпаргалки и мои заметки для подготовки к собеседованиям #собес@eshu_coding

Природа и путешествия #природа@eshu_coding #путешествие@eshu_coding