Хранить редко измененные данные, но часто к ним обращаются, какое решение?

Question

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

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

РЕДАКТИРОВАТЬ: мой оригинальный вопрос слишком общий.Я хочу объяснить это более четко:

У меня есть таблица, которая содержит:

MinValue       MaxValue       PackageID
1                4             1
5                10            2
11               50            3

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

Я использую этот запрос для этого:

select packageid from vmeet_temp where amount between minvalue and maxvalue

Даэто работает.Но так как я неопытный программист, я сомневаюсь, что если есть более эффективный способ архивировать это.

Итак, мой вопрос: для наших нужд, должны ли мы хранить эту информацию в базе данных или нет?Если нет, какое решение пойти?

Answer 1

Храните его в таблице, и пусть СУБД беспокоится об этом.Он имеет кеширование и хорошо справляется с тем, что часто используемые данные хранятся в памяти, поэтому для него не нужно записываться на диск.Если вы действительно хотите, вы можете загрузить данные в свое приложение - вы рискуете (небольшой) риск, что данные будут устаревшими.Но, в общем, пусть СУБД беспокоится об этом, и она сделает это правильно для вас.

Если в таблице всего 10 строк, а строки скромного размера (до нескольких сотен байт каждая),СУБД, вероятно, не будет беспокоиться об использовании индекса, даже если вы его создадите - она ​​знает, что будет проще и эффективнее использовать таблицу напрямую.Даже простодушные оптимизаторы справляются с этим.Очевидно, что если вы забьете его в использование индекса с неуместными подсказками, то вы заплатите штраф за производительность.Если оставить это для своих собственных устройств, вряд ли оптимизатор будет использовать индекс.

Answer 2

Предлагаю вам взглянуть на клиентский кэш результатов в 11g.

Пример: здесь

"Эта функция позволяет на стороне клиента кэшировать наборы результатов запросов SQL в памяти. кэш результатов клиента полностью прозрачен для приложений ODP.NET, и его кеш данных набора результатов автоматически поддерживается в соответствии с любым сеансом или базой данных изменения на стороне сервера, которые могут изменить результаты.

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

Answer 3

Для начала @Jonathan Leffler прав, базы данных действительно хороши для кэширования простых запросов поверх ограниченных данных.Так что, если сервер базы данных не проявляет признаков стресса, таких как высокая загрузка ЦП или дисковый ввод-вывод, то все в порядке.Тогда, если это так, Oracle имеет представления управления , чтобы сообщить вам, какие запросы потребляют наибольшую вычислительную мощность.

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

Если производительность является вашей реальной проблемой, я бы предложил сосредоточиться на нагрузочном тестировании, а не на выявлении узких мест с помощью такого инструмента, как JMeter.Подчеркните итеративно большим количеством потоков, каждый раз записывающих метрики производительности (обычно время отклика страницы), и составляйте график в Excel.Если вы видите экспоненциальную линию, вы обнаружили узкое место.Отключите некоторые и начните добавлять счетчики в код, чтобы увидеть, где замедление.Вы можете обнаружить, что это не имеет никакого отношения к запрашиваемым данным.

Answer 4

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

Вот статья, которая описывает кэширование в .NET

http://msdn.microsoft.com/en-us/library/aa478965.aspx

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

Answer 5

Любой запрос, попадающий в небольшую таблицу, вряд ли будет дорогостоящим по сравнению с другими данными, доступными для типичной системы.

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

Как неопытный программист, вы можете захотеть познакомить себя со следующей цитатой:

преждевременная оптимизация - корень всего зла