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

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

4 голосов
/ 08 февраля 2011

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

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

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

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

Ответы [ 2 ]

6 голосов
/ 08 февраля 2011

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

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

Вы ознакомились с некоторыми из доступных технологий кэширования?

2 голосов
/ 08 февраля 2011

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

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

...