Дилемма дизайна бизнес-уровня: память или IO?

Question

Проект, над которым я работаю, сталкивается с дизайнерской дилеммой о том, как получить объекты и коллекции объектов из базы данных. Иногда полезно буферизировать * все * объекты из базы данных со своими свойствами в память, иногда полезно просто установить идентификатор объекта и запросить его свойства по запросу (1 бит вызова на объект для получения всех свойств). И во многих случаях коллекции должны поддерживать как буферные объекты в памяти, так и инициализироваться с минимальной информацией для доступа по требованию. В конце концов, не все может быть забуферировано в памяти, и не все можно читать по запросу. Это повсеместная проблема памяти и IO.

Неужели кому-то приходилось сталкиваться с той же проблемой? Как повлияли на ваш дизайн? Каковы трудные уроки? Любые другие мысли и рекомендации?

EDIT: мой проект является классическим примером dll бизнес-уровня, потребляемого веб-приложением, веб-сервисами и настольным приложением. Когда список продуктов запрашивается для настольного приложения и отображается только по названию продукта, это нормально, чтобы эта последовательность шагов отображала все продукты (например, в базе данных имеется миллион продуктов):
1. Один дб позвонить, чтобы получить все названия продуктов
2. Один дб вызов, чтобы получить всю информацию о продукте, если пользователь нажимает на продукт, чтобы увидеть детали (доступ по требованию)

Однако, если этот же API будет потребляться веб-службой для отображения всех продуктов с подробной информацией, сетевой трафик станет болтливым. Чем лучше последовательность в этом случае будет:
1. Какого черта, буфер всех продуктов и поле продукта с помощью только одного дб вызова (в данном случае буферного 1 миллион продуктов также выглядит страшно)

Answer 1

Это зависит от того, как часто данные изменения. Обычно кэшируются статические и почти статические данные (обычно с окном истечения кеша).

Базы данных уже разработаны для кэширования данных, поэтому при условии, что сетевой ввод-вывод не является узким местом, пусть база данных делает то, что хорошо.

Вы изучили некоторые технологии кеширования?

• .NET Framework 4 ObjectCache Class

• Cache Class: Using the ASP.NET Cache outside of ASP.NET

• Velocity: Build Better Data-Driven Apps With Distributed Caching

• Object cache for C#

Answer 2

Это не популярный р но избегайте всего кэширования, если это абсолютно необходимо, или если вы точно знаете, что вам понадобится «Интернет-шкала». Пытался раскрыть слоистый кеш поверх базы данных? Собираетесь ли вы писать через кеш и только читать или ждать, когда объект LRU будет записывать изменения? что происходит, когда другое приложение или уровень веб-сервисов сидят на БД и получают несовместимые чтения?

Большинство современных баз данных уже имеют кэш и, вероятно, могут реализовать их лучше вас, просто определите, хотите ли вы ударить по кабелю DB каждый раз, когда вам что-то нужно. В подавляющем большинстве случаев БД будет работать отлично, и вы сохраните свою последовательность.Теория BASE и CAP хороша и интересна, чтобы говорить и воображать, но иногда вы просто не можете победить на рынке, просто попав в добрую старую базу данных. Стресс-тест и определение ваших горячих точек, при необходимости сохраните свой кеш.