LINUX.ORG.RU

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

Исправление den73, (текущая версия) :

Предполагается работать с БД через интерфейс ORM. А коннектов обычно по числу ядер + 2, больше не имеет смысла в нормальной ситуации.

Ну это какое-то... ну нет слов у меня. Т.е., по сути, всё, над чем бились творцы баз данных SQL, и что, собственно и представляет из себя их основную ценность, выбрасывается на помойку. А именно, понятие изолированных параллельных транзакций. Нет, ORM - это не моё. Впрочем, я это уже и раньше знал, а сейчас просто ещё раз проверил.

В кеше первого уровня хранятся данные (таблица, id) -> (столбцы). Если мы делаем любые изменения, то из кеша удаляются все затронутые id.

Если этот кеш хранится на сервере, то для обычной СУБД это особо не нужно. При правильно построенных индексах часто используемые данные находятся в дисковом кеше, и время доступа к ним очень мало. Если же кеш хранится на клиенте, сервер должен собирать от коннектов и рассылать клиентам информацию об устаревании данных в кеше. Как минимум, при этом возникает ещё один показатель производительности, за которым надо следить, а предсказуемость производительности приложения на клиентской стороне сильно снижается. Хотя эта проблема менее значима, чем потеря понятия изолированных транзакций.

Исходная версия den73, :

Предполагается работать с БД через интерфейс ORM. А коннектов обычно по числу ядер + 2, больше не имеет смысла в нормальной ситуации.

Ну это какое-то... ну нет слов у меня. Т.е., по сути, всё, над чем бились творцы баз данных SQL, и что, собственно и представляет из себя их основную ценность, выбрасывается на помойку. А именно, понятие изолированных параллельных транзакций. Нет, ORM - это не моё. Впрочем, я это уже и раньше знал, а сейчас просто ещё раз проверил.

В кеше первого уровня хранятся данные (таблица, id) -> (столбцы). Если мы делаем любые изменения, то из кеша удаляются все затронутые id.

Если этот кеш хранится на сервере, то для обычной СУБД это особо не нужно. При правильно построенных индексах часто используемые данные находятся в дисковом кеше, и время доступа к ним очень мало. Если же кеш хранится на клиенте, сервер должен собирать от коннектов и рассылать клиентам информацию об устаревании данных в кеше. Как минимум, при этом возникает ещё один показатель производительности, за которым надо следить, а предсказуемость производительности приложения на клиентской стороне сильно снижается. Хотя эта проблема менее значима, чем потеря понятия изолированных транзакций.