наверное идеальный случай, когда получается расширить возможности платформы и просто завести его как отдельный tenant, выделив какие доп ресурсы в облаке

если сделать его отдельным silo, то мне кажется потом влить его обратно будет нереально(вопрос конечно нужно ли)

в смысле производительности?

нет, в смысле количества клиентов

у нас пока такой проблемы нет и не планируется. Но да, это более проблемно, особенно если люди хотят для каждого клиента иметь отдельный стейджинг

прост клиентов мало пока

почему же? если у тебя весь процесс деплоя и тестирования автоматизирован, если у тебя миграции данных полностью автоматизированы и надежны (что реализуемо), если у тебя весь процесс провиженинга автоматизирован - то в целом silo как раз проще. Причем все перечисленное по идее проще чем надежная pool модель.

Сложность именно в cost optimizations. Если ты юзаешь например какой-нибудь dynamodb то у тебя вопрос эффективной утилизации ресурсов из этого уравнения в целом исключается. Платишь только за то сколько юзаешь и скейлинг оно там само разрулит

bridge частично тоже уменьшает количество проблем с cost optimizations - все еще проще pool и появляется возможность шарить инфраструктуру и за счет этого лучше рулить костами

ну вот чтобы скейлить silo надо все эти если пройти, что сложнее. Для pool они не являются необходимостью до тех пор, пока не надо партицированием заниматься

привет... а есть группы где холливары по выбору СУБД?

А чем этот не подходит)

не верь ему. он тебя подначивает а потом забанит)

Короче выбираю скажем так хранилище или два... 1 задача быстро складывать json ы в коллекции... 2 задача фасетный поиск по этим Json.  Всё что связано с деньгами я уже решил запихнуть в реляционку. Некоторые говорят не гоже хранить в эластике... Хранить надо в монге или реляционке а потом уже в эластик заливать

зависит от требований по надежности стора, как часто как много обновляется, какие требования к времени восстановления при факапах и т.д. У эластики было полно проблем с репликацией до 7-ой версии, сейчас должно быть получе но стоит ресерчить + отдельно вопросы бэкапов прорабатывать.

Фасеточный поиск можно и на редисе сделать и хранить json-ки где удобно. Хоть в той же реляционке.

скажем если не страшно чуть данные "потерять по ходу дела" то можно тупо в эластике хранить

Привет.
Кто занимается сбором и анализом фич-реквестов?
Это продукт-менеджмент ? Или аналитика?
Если это продукт менеджмент, то какая область / раздел?

в вакууме - продукт менеджер. В конкретной компании - как организуете. Может быть например некий бизнес аналитик в начале когда не совсем понятно "какой из продукт менеджеров тут лучше подойдет". Эдакая фильтрация/маршрутизация на входе. Могут и супорты этим заниматься, скидывать все это в помойку которую уже продукты разбирают. Бывают всякие solution design отделы... или сэйлы... но по хорошему продукт менеджер как роль потом занимается фильтрацией и т.д. Бизнес аналитика (как тайтл) может выступать в роли продукт менеджера (роль)

а насколько быстро надо складывать json-ы и примерно что в них

Принято.
Спасибо.

Читал пару статей про 200 и 600 тб на эластике... Понятно что дублировать уже задублированное и шардированное это ещё больше проблем. По ходу старую базу надо тупо перелить по одной записи и получится тестирование 😂