СУБД как кеш, нужны советы по дизайну - PullRequest
Новая
       59

СУБД как кеш, нужны советы по дизайну

0 голосов
/ 24 ноября 2011

У меня есть приложение «черного ящика», которое получает карту значений в качестве параметров, выполняет тяжелые и длинные (до 5 с) вычисления и генерирует единичное Result, которое можно сохранить в базе данных. Все, что я знаю об этом приложении, это:

  • Результат уникален по отношению к предоставленным значениям карты
  • Аргумент - это String-> String map с известной максимальной длиной обоих ключ и значение
  • Карта аргументов переменной длины (от 2-3 до 1000 записей или поэтому)
  • Размер списка возможных ключевых значений составляет около 1000

Примеры аргументов: 

Map: {'k1'->'a', 'k2'->'b'} 
Map: {'k1'->'a', 'k2'->'b', ... 'k100'->'zzz'}
Map: {'k1'->'x', 'k8'->'y'}
Map: {'k6'->'z'}

Каждый из вышеперечисленных произведет уникальный Result объект.

Теперь представьте себе другой сервис, который построен на основе этой медленной библиотеки и должен работать в режиме онлайн и обрабатывать десятки запросов на вычисления в секунду. Это невозможно без кэширования уже рассчитанных результатов. Моя оценка общего количества возможных размеров кэша составляет примерно 100-500 миллионов записей, что приводит меня к использованию СУБД в качестве хранилища кэша.

Поскольку результат однозначно определяется по предоставленной карте, я мог бы отсортировать аргумент карту по ключу и объединить его в строку 'k1: a: k2: b ....'. Это определенно будет ключ кеша, но:

  • Ключ кэша будет огромным, выше предела размера ключа для многих СУБД и требуется индексированный CLOB
  • Я не буду использовать тот факт, что значения ключей ограничены в возможные значения.

Что бы вы посоветовали? Производительность - моя главная проблема здесь.

Ответы [ 2 ]

2 голосов
/ 24 ноября 2011

На самом деле это больше похоже на проблему, которую лучше всего решить с помощью хранилища значений ключей или базы данных документов , а не СУБД.

Еще одна возможность, которую стоит рассмотретьтакой сервер кэширования, как memcached .

1 голос
/ 24 ноября 2011

Мой вам совет - подсчитать, сколько будет 500М * 5сек, выраженное в днях.Это время, которое потребуется для вычисления всех результатов, которые вы будете хранить в своем кэше, и это время, которое потребуется до того, как вы начнете видеть реальную выгоду от создания этого кэша.

(Да, я знаю, вы можете создавать свой кэш «постепенно». Но если существует так много возможных записей, то вероятность попадания просто пропорциональна самому размеру кэша, то есть: почти нет вообщев фазе запуска. И это займет много времени, прежде чем вы достигнете разумного уровня вероятности попадания. imho.)

...