Должен ли я хранить справочные данные в памяти моего приложения или в базе данных? - PullRequest
0 голосов
/ 13 февраля 2010

Я столкнулся с выбором, где хранить некоторые справочные данные (по существу, выпадающие значения) для моего приложения. Эти данные не изменятся (или, если это произойдет, мне нужно перезапустить приложение), и к ним будет часто обращаться как к виджету автозаполнения AJAX (так что один пользователь может заполнить несколько запросов к этим данным, заполнив один поле).

Предположим, что каждая запись выглядит примерно так:

category
effective_date
expiration_date
field_A
field_B
field_C
field_D

Запрос автозаполнения должен будет проверить входную строку по 4 полям в каждой записи и дискретные параметры по категории и датам действия / истечения срока действия, поэтому, если бы это был SQL-запрос, он имел бы предложение where, которое выглядит примерно так:

... WHERE category = ? 
AND effective_date < ?
AND expiration_date > ? 
AND (colA LIKE ? OR colB LIKE ? OR colC LIKE ?)

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

Альтернатива, которую я вижу, - сохранить ее в памяти моего приложения. Я мог бы получить список этих записей для каждой категории, а затем выполнить итерацию по каждой записи в категории, чтобы посмотреть, удовлетворены ли критерии фильтрации. Это определенно O (n), так как мне нужно изучить каждую запись в категории.

Кто-нибудь сталкивался с подобным выбором? Есть ли у вас какие-либо идеи, чтобы предложить?


РЕДАКТИРОВАТЬ: Спасибо за понимание, ребята. Отправка всего набора данных клиенту на самом деле не вариант, так как набор данных очень большой (несколько МБ).

Ответы [ 3 ]

1 голос
/ 13 февраля 2010

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

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

Учитывая количество направлений, по которым вы получаете эти данные (фильтрация по 6 или более столбцам), я не уверен, насколько больше вы сможете оптимизировать информацию в памяти. Первое, что я бы попробовал, это сохранить его в списке в объекте Application и запросить его, используя LINQ-to-objects. Или, если есть одно поле, которое используется значительно больше, чем другие, или попробуйте использовать словарь вместо списка. Если производительность по-прежнему остается проблемой, попробуйте сохранить ее в DataSet и установить для нее индексы (но, конечно, вы потеряете некоторую простоту кода и удобство обслуживания).

0 голосов
/ 13 февраля 2010

Можете ли вы просто подключить его к программе (пока вы придерживаетесь DRY)? Для его изменения требуется только перестройка.

0 голосов
/ 13 февраля 2010

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

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

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

...