У меня есть задача создать прототип для масштабируемого масштабируемого приложения с распределенной общей памятью (DSM). Прототип будет служить только доказательством концепции, но я хочу потратить свое время наиболее эффективно, выбрав компоненты, которые будут использоваться в реальном решении позже.
Цель этого решения - взять данные из внешнего источника, отбросить его и сделать доступным результат для ряда интерфейсов. Эти "интерфейсы" просто берут данные из кеша и обслуживают его без дополнительной обработки. Количество обращений к этим данным в реальном времени может составлять миллионы в секунду.
Сами данные очень нестабильны; он может (и делает) меняться довольно быстро. Однако интерфейсы должны видеть "старые" данные до тех пор, пока новейшие не будут обработаны и не будут кэшированы. Обработка и запись выполняются одним (избыточным) node, в то время как другие узлы только считывают данные. Другими словами: без чтения.
Я искал такие решения, как memcached, однако этот конкретный не выполняет все наши требования, которые перечислены ниже:
- Решение должно по крайней мере иметь API-интерфейс Java, который достаточно хорошо поддерживается, поскольку остальное приложение написано на Java, и мы являемся опытными разработчиками Java;
- Решение должно быть полностью эластичным: должно быть возможно добавлять новые узлы без перезапуска других узлов в кластере;
- Решение должно иметь возможность обрабатывать failover. Да, я понимаю, что это означает некоторые накладные расходы, но общий размер данных для обслуживания невелик (максимум 1G), поэтому это не должно быть проблемой. Под "отказоустойчивостью" я подразумеваю бесшовное выполнение без жесткого кодирования/изменения IP-адресов (серверов) сервера, как в memcached-клиентах, когда node опускается;
- В идеале должно быть возможно указать степень перекрытия данных (например, сколько копий одних и тех же данных должно храниться в кластере DSM);
- Нет необходимости постоянно хранить все данные, но может потребоваться постобработка некоторых данных (например, сериализация в БД).
- Цена. Очевидно, что мы предпочитаем бесплатный/открытый источник, но мы счастливы заплатить разумную сумму, если решение того стоит. В любом случае, оплачиваемый контракт на 24 часа в сутки является обязательным.
- Все это должно быть размещено в наших центрах обработки данных, поэтому предложения SaaS, такие как Amazon SimpleDB, недоступны. Мы бы рассматривали это только в том случае, если бы не было других вариантов.
- В идеале решение будет строго последовательным (как в CAP); однако возможная консистенция может рассматриваться как вариант.
Заранее благодарим за любые идеи.