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

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

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

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

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

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

#postgresql
#conf

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

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

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

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

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

#conf
#highload

Ну чтож, пора подвести итоги года. В прошлом январе я писал планы. Итого, по пунктам:
1. Прочитал страниц 50 из Рихтера:)
2. DDD я покушал от души.
3. Не добрался
4. Не добрался
5. Не добрался
6. Не добрался
7. Не добрался

Э - эффективность, П - планирование.

Из позитивных итогов:
1. Вспомнил и прокачал SQL без ORM.
2. Познакомимся с чудесным продуктом для построения отчётов - FastReports. Теперь я точно знаю, что лучшее, что с ним можно сделать - удалить его к чёртовой матери.
3. Посмотрел и отрефлексировал многие глобальные вещи, касающиеся архитектуры и организации разработки.

Планы на 2025 надо будет тоже озвучить, но это несколько позже.

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

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

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

#conf
#highload

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

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

#conf
#highload

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

Посмешу богов уже в третий раз. Мои планы на 2025 год.

1. Традиционно не выполняющийся пункт - вернуться к чтению и конспектированию умных книжек.
2. Хочу вкатиться поглубже в шарповый ui фреймворк AvaloniaUI.
3. Традиционно не выполняющийся пункт - вкатиться в мир алгозадачек.

Наверное этого хватит:)

Пожалуй пришло время обновить закреплённый пост. Каналу уже 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

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

Столкнулся с необходимостью саггрегировать логи, хранящиеся в Opensearch, надо было взять уникальные сообщения об ошибках, по 1 шт. Логов после всех фильтров немного, десятки тысяч строк. Визуальный конструктор запросов не предложил ничего внятного, пошел в гугл - предлагает писать запросы в виде json-ов, как монга, но синтаксис естественно отличается.

С мыслью "вы наркоманы что-ли, ещё один оригинальный язык запросов?!" я отправился к нейронке, но она не помогла. Тогда я выгрузил результат как csv и нижеприведенным кодом на шарпе решил проблему.

var data = File.ReadAllLines("Книга1.csv")
  .Select(line => line.Split(',')[2])
  .Distinct()
  .ToArray();
            
File.WriteAllLines("Книга2.csv", data);

Теперь печально задаюсь вопросом, почему каждая no-sql кочка изобретает свой язык запросов, а завозят ограниченную поддержку SQL для типовых ситуаций - далеко не все.

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

#природа