В нашем случае необходимости в «зоопарке» не было — наоборот, мы упростили всю систему, исключив rabbit, kafka, elastic search и др. FTS (full-text search) в PG позволяет находить необходимые данные в базе из миллионов документов за 2-3 мсек — для наших задач более чем достаточно.
Тут вопрос скорее не базы, а философии (как организовать структуру данных и где обрабатываются данные). Подобный подход наверняка можно реализовать в любой качественной БД.
Кроме того, пока не обнаружено каких-либо подводных камней в PG — весь необходимый функционал есть, шикарная скорость (особенно на классических B-Tree индексах), работа с json(b) тоже выше всяких похвал.
Инструкции микросервису дает база в ответе, в специальном атрибуте.
Если базе надо получить внешние данные, то в этом атрибуте заполняются необходимые параметры — и микросервис выполняет инструкцию и затем дергает хранимку, уже с дополнительными данными. Но такие кейсы нечасто происходят (не более 1% от общего числа запросов)
Кроме того, пока не обнаружено каких-либо подводных камней в PG — весь необходимый функционал есть, шикарная скорость (особенно на классических B-Tree индексах), работа с json(b) тоже выше всяких похвал.
Мы уже более года живем на новом бэке — пока только положительные эмоции. Новые статьи не за горами — подписывайтесь на наш блог
Все зависит от конкретного проекта.
Если базе надо получить внешние данные, то в этом атрибуте заполняются необходимые параметры — и микросервис выполняет инструкцию и затем дергает хранимку, уже с дополнительными данными. Но такие кейсы нечасто происходят (не более 1% от общего числа запросов)
CONSTRAINT entity_list_pkey PRIMARY KEY (entity_id, key_id)
INCLUDE(index_scan)
Во-вторых, прогресс в Постгрес в области работы с json и хранимок в целом за последние 3 года был колоссальный.
habr.com/ru/company/lingualeo/blog/515530/#comment_21964956