Комментарии 23
Короче, статья об элегантном решении проблемы, которая в принципе не может возникнуть в компании с адекватной культурой разработки
С интересом почитал по ссылке. К сожалению, комментировать там не могу по сроку давности)
Но, мне кажется, что MSSQL с CCI на хорошей железке с достаточным объемом RAM и ядер (и ручным указанием maxdop) решает процентов 90 описанных проблем. Возможно, clickhouse тоже, но у меня он споткнулся на весьма простых запросах типа join таблицы на саму себя по условию, перейдя в однопоточный просчет, что совсем уж печально (возможно, я дзен не познал, или руки кривые). И, предполагаю, что Google big query тоже решает проблему, но я исторически скептик облаков)
Касательно M$:
1) очень хитрожопые группировки выполняются на таблице размером 2млрд×60 за пару минут. Если через where отсекаешь партиции, пропорционально быстрее.
2) новые столбцы добавляются мгновенно
3) на время запроса влияют только столбцы, которые в нем участвуют
4) распараллеливание реально работает
5) если работать в append-only режиме, то тысячи TPS тянет.
6) пролицензировать все ядра для мощного сервера лицензией по ядрам ОЧЕНЬ дорого, а лицензия не по ядрам позволяет задействовать 20 логических ядер, что неактуально для современного железа.
Поэтому, берется делается большая колоночная партиционированная таблица. На каждый чих добавляется по колонке. Любые коррекции пишутся, как +1 строка с дельтой, и, соответственно, почти любое чтение содержит group by id. Ну как-то так)
Так а чем вызвано неприятие связки full scan + SQL?
И да, из документных только монго приходит на ум, и делать на нем аналитику — это для любителей бдсм) Да и вообще, из реального опыта, мерзкая вещь для почти всех сценариев кроме 2-3 специфических.
Описанное — это только первый шаг. Вы уже поняли, почему плохо лазить напрямую в БД другого сервиса — это хорошо.
Теперь вы решили заняться репликацией БД другого сервиса через поток событий содержащих полные данные… как говорится, сложные проблемы всегда имеют простые, легкие для понимания неправильные решения. Но — попробуйте делать как запланировали, некоторое время это решение проработает, как проработало предыдущее с чтением из чужих БД.
Потом вы осознаете, почему дублировать полностью все изменения БД одного сервиса в публичный лог событий предназначенный для других сервисов — плохо, и сделаете следующий шаг: будете стараться включать в события только тип события и ID связанной с событием сущности, добавив каждому сервису API, позволяющее получить практически сырые данные из его БД по этому ID.
А ещё через некоторое время, наконец, поймёте, что все эти подходы "в лоб, грубой силой", с микросервисами не работают, и начнёте учиться тому, как надо определять границы между микросервисами, чтобы получить не распределённый монолит и много-много боли в нагрузку, а настоящую микросервисную архитектуру.
Уже много-много раз говорилось: микросервисная архитектура просто переносит часть сложности из кода сервисов на архитектора, чем сильно повышает требования к квалификации архитектора. Если у вас пока нет действительно сильного архитектора, с серьёзным опытом разработки микросервисных архитектур, то лучше бы вам не мучить свой проект, а постараться вернуть его в состояние монолита, и для масштабирования использовать более традиционные для монолитов подходы (шардинг, вынесение тяжёлых операций во внешние сервисы-воркеры, etc.).
В качестве хорошего примера, как надо подходить к разработке микросервисной архитектуры, посмотрите на ютубе выступления Udi Dahan. Например (правда, это не для начинающих), очень показательный кейс с медициной, как иллюстрацию ситуации в которой традиционные подходы не работают, и как при этом приходится выкручиваться: Finding Service Boundaries – illustrated in healthcare by Udi Dahan.
Это так, но Вы несколько расширили контекст, и мы так докатимся до вывода, что все участники проекта, от заказчика до бета-тестеров, должны быть супер профи, и вот тогда всё будет хорошо.
Бизнес-аналитику не важно, используется ли монолит или микросервисы. Кроме того, даже если архитектор видит "полную картину", это не сильно облегчает ему жизнь — требования постоянно меняются, и эта "полная картина" через месяц-два может сильно мутировать, так что требовать от бизнес-аналитика супер точную и полную картину менее полезно, чем быть готовым адаптировать архитектуру под новые требования.
требовать от бизнес-аналитика супер точную и полную картину менее полезно
Команда либо есть, либо ее нет, а от нее зависит очень многое. На одном мастерстве архитектора в прямой постановке вопроса, далеко не уедешь, максимум плавание по течению.
1. Часто для обработки события нужно иметь дополнительную информацию об измененной сущности, что влечет «уточняющие» запросы подписчиков к API микросервиса
2. Желание решить предыдущую проблему добавлением в событие всей нужной информации вызывает перегрузку сети бесполезно передаваемыми данными
3. Важно понимать что события это тоже API, поэтому менять их семантику или содержание нужно с теми же самыми предосторожностями (версионирование, обратная совместимость и т.п.)
Ваши распределенные монолиты плетут козни у вас за спиной