История изменений

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

Я прямо сейчас занимаюсь проектом, который очень близкую функцию выполняет. Одно из первых применений, которое я ему пророчу — это тот самый кэш объектов, который ты описываешь. Проблему с доступом к read-only хранилищам уже решила plasma, которая на Apache Arrow.

Основная проблема в сценарии, который ты описываешь — это толстый интерфейс между кодом, генерирующим конечный контент, и базой данных. Хэш-таблица, хранящая твои кэшированные объекты — это та же база данных. Ты просто создал вторую базу данных, как я уже написал, и делаешь запросы к ней, а не к основной СУБД. Предлагаю тебе придумать, как ты будешь организовывать эффективное обнаружение изменений, если пользователей много и они достаточно часто меняют ники. То есть, тысячи пользователей, из которых десятки в день меняют ники. Тот же Youtube очень просто решил эту проблему, то есть — никак. Пользователям показывается тухлая инфа, которая когда-нибудь обновится.

С таким же успехом систему можно развернуть наоборот: сделать основное хранилище в памяти бизнес-логики, а реляционная база будет вспомогательынм хранилищем, обеспечивающим persistence. И тогда проблема с обновлением исчезает, потому что все обновления прежде всего проходят через бизнес логику.

Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты. (И есть шанс, что что-то уже будет в кэше, возможно даже всё)

А отдать данные с полного датасета пользователю в виде HTML — это типа быстро, что ли? Сделать «Select first 10...» намного быстрее напрямую из базы, чем ворошить кэш, например.

Если же у тебя большая часть обработки делается на бизнес-логике, а пользователю отдается малая доля инфы — то у тебя и основная база должна быть в бизнес-логике.

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением. Иначе не совсем понятно, чем плох обычный map по датасету

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

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

Я прямо сейчас занимаюсь проектом, который очень близкую функцию выполняет. Одно из первых применений, которое я ему пророчу — это тот самый кэш объектов, который ты описываешь. Проблему с доступом к read-only хранилищам уже решила plasma, которая на Apache Arrow.

Основная проблема в сценарии, который ты описываешь — это толстый интерфейс между конечным, генерирующим конечный контент, и базой данных. Хэш-таблица, хранящая твои кэшированные объекты — это та же база данных. Ты просто создал вторую базу данных, как я уже написал, и делаешь запросы к ней, а не к основной СУБД. Предлагаю тебе придумать, как ты будешь организовывать эффективное обнаружение изменений, если пользователей много и они достаточно часто меняют ники. То есть, тысячи пользователей, из которых десятки в день меняют ники. Тот же Youtube очень просто решил эту проблему, то есть — никак. Пользователям показывается тухлая инфа, которая когда-нибудь обновится.

С таким же успехом систему можно развернуть наоборот: сделать основное хранилище в памяти бизнес-логики, а реляционная база будет вспомогательынм хранилищем, обеспечивающим persistence. И тогда проблема с обновлением исчезает, потому что все обновления прежде всего проходят через бизнес логику.

Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты. (И есть шанс, что что-то уже будет в кэше, возможно даже всё)

А отдать данные с полного датасета пользователю в виде HTML — это типа быстро, что ли? Сделать «Select first 10...» намного быстрее напрямую из базы, чем ворошить кэш, например.

Если же у тебя большая часть обработки делается на бизнес-логике, а пользователю отдается малая доля инфы — то у тебя и основная база должна быть в бизнес-логике.

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением. Иначе не совсем понятно, чем плох обычный map по датасету

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

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

Я прямо сейчас занимаюсь проектом, который очень близкую функцию выполняет. Одно из первых применений, которое я ему пророчу — это тот самый кэш объектов, который ты описываешь. Проблему с доступом к read-only хранилищам уже решила plasma, которая на Apache Arrow.

Основная проблема в сценарии, который ты описываешь — это толстый интерфейс между конечным, генерирующим конечный контент, и базой данных. Хэш-таблица, хранящая твои кэшированные объекты — это та же база данных. Ты просто создал вторую базу данных, как я уже написал, и делаешь запросы к ней, а не к основной СУБД. Предлагаю тебе придумать, как ты будешь организовывать эффективное обнаружение изменений, если пользователей много и они достаточно часто меняют ники. То есть, тысячи пользователей, из которых десятки в день меняют ники. Тот же Youtube очень просто решил эту проблему, то есть — никак. Пользователям показывается тухлая инфа, которая когда-нибудь обновится.

С таким же успехом систему можно развернуть наоборот: сделать основное хранилище в памяти бизнес-логики, а реляционная база будет вспомогательынм хранилищем, обеспечивающим persistence. И тогда проблема с обновлением исчезает, потому что все обновления прежде всего проходят через бизнес логику.