Polyglot persistence это не просто про "не зависеть от хранилища" - это про "использовать наиболее эффективное хранилище для задачи".

То есть одни и те же данные иметь возможность мэпить на разные модели - графовую, колоночную, etc.

Если нужна общая транзакция, то её ни в чём нельзя

То есть мы можем в целом мастер данные персистить через ar и из них строить проекции

Саги

Словом polyglot persistence это про разные сторы в одном приложении а значит ORM тут не причем

Это другое (c)

Ну или и у ar и у data mapper одинаковые шансы помочь тебе этот полиглот персистенс добиться

Не надо путать это с абстракцией от хранилища - я бы сказал это прям противоположные концепты

В общем, если имеется в виду одну сущность сохранять в разные хранилища, то с DM можно, а с AR обычно нет.

Если же надо разные части одной сущности раскидать по разным хранилищам, то это везде можно.

Короч вопрос не корректный.

саммари

для начала надо уточнить что мы подразумеваем под полиглот персистенс. Можно предложить два кейса - простой и сложный.

простой кейс - делаем мы инстаграм какой. "лайки у нас будут храниться в dynamodb, репосты в neo4j каком. Сами фотки будем хранить в postgresql (просто так), ну и всякое такое. Суть в том что для каждой задачи мы выбираем максимально оптимальный стор.

сложный кейс - когда одни и те же данные на запись нужны в одном виде, и потом у нас много вариантов чтения. Нужны агрегации какие-то для репортов и аналитики, нужна статистика и т.д. То есть данные попадают в систему, персистятся в какой-то мастер, и из мастера потом генерим проекции в нужные хранилища оптимальные для решения задачи. Это прям один из ключевых пунктов за который тот же event sourcing продают как один из вариантов этого добиться.

Исходя из этого нельзя говорить о том что ORM хоть как-то влияет на вопрос достижения polyglot persistance. Просто потому что одна ORM - один стор. Не надо путать возможность "заменить стор в процессе эксплуатации" и "оптимизации модели данных под задачу"

ты ж понимаешь что основная проблема с полиглот персистенс это не как данные замэпить, я вполне себе могу представить такой вариант и с AR (хоть это и будет тупо). Сложность именно в поддержании консистентности стэйта когда у тебя этот стэйт распределен по разным сторам. Сложность в поддержании ссылочной целостности и т.д.

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

все так. AR просто позволяет мэпить некие данные 1:1 на "объект". Отлично подходит для задач когда логика простая (тупой круд коего полно в приложениях любой сложности).

Но AR тебе не поможет например "сохранить в postgresql а потом убедиться что стэйт в elasticcache будет актуальным". Для этого тебе нужно уже что-то еще. В прочем data mapper тоже не позволит этого сделать. Тут нужны либо outbox всякие, либо ивенты и процессинг отдельный и т.д.

опять же - полиглот персистенс именно о том что "нужно зависеть от хранилищя и выбирать это хранилище под задачу". то есть ты берешь то хранилище которое оптимально подходит для нужной тебе модели данных. Удобно с графами работать? Берешь neo4j. Нужно интенсивно работать со структурами данных какими - берешь redis условный. Нужно хранить и агрегировать оч много time serias метрик - берешь какой кликхаус и прочее.....

То есть каждую маленькую фичу мы максимально завязываем на хранилище что бы получить от этого хранилища максимальный профит.

Важно понимать что большинство этих кейсов это чтение. То есть "в любом случае не выйдет актуальность данных гарантировать". Возможно небольшое отставание там и т.д. И обычно "это ок".

Ну а для агрегатов которые тебе будут уже imidiate constency гарантировать достаточно тупого key-value стора.

А я вот возьму и порекомендую книжку - Teams Topology. Она не про экторы и не про микросервисы но оттуда может быть будет понятно зачем оно все нужно и почему каждый второй стартап грезит ими...

о, спасибо большое

а про экторы можно оригинальную публикацию Карла Хьюита почитать...

https://teamtopologies.com/
оно?