Помните раньше говорил что у ChatGPT большие проблемы с математикой. Теперь разработчики из OpenAI доработали модель и вместо того чтоб пытаться посчитать это текстом, он пишет скрипт, выполняет его на настоящем интерпретаторе и затем использует результат в ответе.

Коллеги, хочу немного свичнуться с темы Java на базы данных и в этот раз не рассказать что-то из головы, а спросить у вас.

Сейчас рассматриваю опции апгрейда наших миграций на текущем проекте. Сейчас это обычный flywaydb который на старте сервиса накатывает миграции. Достаточно топорно и просто. Возникла проблема с тем что на CI/CD стоят таймауты чтоб мониторить состояние поднимающихся подов и когда они заняты добавлением индексов или другими тяжелыми миграциями - они просто отваливаются по таймауту.

Думаем над несколькими возможными сценариями между запуском асинхронных миграций внутри такущего CI/CD или выносом миграций во внешнее репо, отвязывание их текущего деплойного процесса и разумеется еще "более асихнхронное" их выполнение.

Как на ваших проектах решается данная проблема? или может вам в последнее время попадались какие-то релевантные статьи или выступления? Буду очень признателен! а по итогам будет новая тема тут ^^

Quiz time! Вопрос - в следующем посте. ⬇️

Очень рад, что ChatGPT теперь имеет встроенного DALL-E, который умеет рисовать. Жаль что он пока совсем-совсем не умеет в схемы и графики ?

KISS в архитектуре
Нужен ли Redis?

Сразу оговорюсь - оцениваю технологии с высоты собственного опыта на PHP и Java-стеке. Если есть идеи или мысли что я что-то упустил или не так посчитал - обязательно пишите в комменты, обсудим!

Итак, давайте оценим Redis, как яркого представителя кэш систем, и оценим прирост производительности по сравнению с “только СУБД”. Не буду рассматривать сложные штуки, например дополнительные структуры типа списков, деревьев и блокировок. Предположу, что соотношение производительностей этих структур будет аналогичным.

Итак, по оценке ChatGPT на среднем современном сервере производительность Redis при работе в режиме key-value с 80% read нагрузкой и 20% write составляет 420к операций в секунду. Аналогичный вариант при работе с 2 столбцами primaryKey + text в одной таблице в PostgreSQL сможет выдать ~82к операций в секунду при условии что таблица достаточного размера, чтоб находиться постоянно в памяти. Для меня эти оценки выглядят очень реалистичными. Давайте скажем, что Redis в любом режиме выдает 5х производительности по сравнению с СУБД размеры данных в которой позволяют им всегда находиться в кеше. Много это или мало? Думаю, что достаточно ответить на вопрос - много ли проектов на нашем опыте действительно упираются в производительность СУБД по живой нагрузке, а не по причине неправильных, причем зачастую аналитических, запросов. За 12 лет опыта работы видел такие проекты только на сценах конференций. Это конечно интересно но правда ли redis нужен на конкретно вашем сегодняшнем проекте? Те мои проекты, которые использовали memcached или redis, могли бы положить их в общую бд с тем же результатом и с минимальными просадками по скорости работы. В абсолютном большинстве проектов где я работал 99% нагрузки на реляционную БД генерируется аналитическими запросами, и даже в этих случаях общая нагрузка на БД редко превышает 20-50%, иначе запускается очередной цикл оптимизации аналитических запросов силами инженеров.

В итоге, подозреваю, что 95-98% современных проектов могут легко обойтись без in-memory специализированных решений. Это позволяет тянуть меньше технологий в проект, упрощать схему инфраструктуры, уменьшать количество точек отказа, делать проще требования к новым инженерам. Звучит очень выгодно! А вы что думаете? ^^

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

KISS в ахритектуре

Возьмем две продуктовые компании.

Компания А разрабатывает продукт на стеке Java, PostgreSQL, Kafka, Redis, ElasticSearch и CI/CD наборе. Для упрощения предположим что у технологий одинаковая сложность равная единице. Итак, суммарная технологическая сложность продукта компании А - 6. Предположим средний сотрудник обладает 3 глубокими релевантными скилами по технологиям. Наняв 10 сотрудников получим среднее покрытие в виде 5 инженеров на технологию. Разумеется, Java и СУБД знает почти каждый инженер, а остальные технологии по остаточному принципу, но как минимум по 1-2 человека на технологию.

Компания B - разрабатывает аналогичный продукт на стеке Java, PostgreSQL и CI/CD наборе. Наняв 10 аналогичных сотрудников мы получим среднее покрытие в виде 10 человек на технологию. Следствием будет более высокий BusFactor и меньшие риски от ухода отдельных людей.

Пример, конечно, грубый. Но на личном опыте видел, как необоснованно внедренные технологии требовали буквально выделенных людей для поддержки этих технологий. Либо общий скилл инженеров был недостаточен и дополнительные технологии не добавляли никаких бонусов от использования. Дополнительные технологии так же влияют на сложность CI/CD процесса и стоимость инфраструктуры. Не говоря уж о том, что они добавляют новые точки отказа в продукт.

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

KISS в архитектуре

Пару последних и несколько следующих постов хочется объединить этим заголовком. И для продолжения повествования - напомню что это такое:

KISS - Keep It Simple, (Stupid/Soldier/Sailor). Это принцип, который говорит что использование максимально простого подхода или решения предпочтительнее оверинжиниринга. С моей точки зрения это важно помнить и при написании кода, и при планировании базы данных, и при когда проектируете продукт любого масштаба.

И еще один термин который понадобится это:

Bus factor - неформальный термин относящийся к управлению проектами, который определяет количество критически важных сотрудников на проекте. Это то количество сотрудиков, попадание которых "под автобус", нанесет критически серьезный ущерб проекту. Например, если на проекте только один человек обладает специфичными знаниями, то bus factor равен единице. И это, разумеется, рискованно для проекта.

Небольшой и, наверное, очевидный спойлер: использование KISS на высокоуровневом проектировании проекта автоматически повышает bus factor и снижает риски для проекта.