Альтернатива распределенному кешированию - PullRequest
Новая
       37

Альтернатива распределенному кешированию

2 голосов
/ 10 мая 2010

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

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

Проблема в том, что один или два из трех уровней требуют интенсивного кэширования (около 3 миллионов записей и увеличивается).

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

Я сейчас смотрю на ncache, но мне просто интересно, есть ли альтернативы этой проблеме? или есть какая-либо другая сопоставимая система распределенного кэширования, которая может быть аналогична или лучше, чем ncache, и также обеспечивает поддержку предприятия?

Спасибо

Chen

Ответы [ 2 ]

1 голос
/ 10 мая 2010

В этой статье IBM вы можете найти (с истекшим сроком действия) основных действующих лиц в среде DCP (платформы распределенного кэширования).

Альтернатива, которую мы используем (не бесплатно): Gigaspace XAP .

http://wiki.gigaspaces.com/wiki/download/attachments/55935974/XAP%20Architecture%20Overview.jpg

0 голосов
/ 12 августа 2013

Чен -

Похоже, что вы определенно могли бы использовать распределенную систему кэширования или даже сетку данных в памяти (IMDG). Вот некоторые основные моменты Oracle Coherence (ранее Tangosol Coherence):

  • эластичный. Просто добавьте узлы. Автоматическое обнаружение. Автоматическое распределение нагрузки. Нет потери данных. Нет перерыва. Каждый раз, когда вы добавляете узел, вы получаете больше емкости данных и большую пропускную способность.
  • Используйте память и флэш-память. Прозрачное. Легко обрабатывать 10 или даже 100 гигабайт на узел Coherence (например, до ТБ или более на физический сервер).
  • Автоматическая высокая доступность (HA). Убить процесс, без потери данных. Убить сервер, без потери данных.
  • Постоянная доступность центра обработки данных (CA). Убить центр обработки данных, без потери данных.
  • RESTful API доступны на любом языке. Собственные API и клиентские библиотеки для C / C ++, C #, .NET и Java.
  • Помимо простого кэширования значения ключа (K / V), также поддерживаются запросы (включая некоторые SQL), параллельные запросы, индексы (включая пользовательские индексы), богатая модель событий (для управляемых событиями систем, таких как обмены), транзакции (включая MVCC), параллельное выполнение как скалярных (EntryProcessor) и агрегатных (ParallelAwareAggregator) функций, триггеров кэширования и т. д.
  • Простота интеграции с базой данных с помощью кэширования с возможностью чтения, упреждающего чтения, сквозной записи и обратной записи. Автоматически обновляет только измененные данные, когда изменения происходят в базе данных (используя технологию Oracle GoldenGate).

Существует сводка рынка Gridner In-Memory Data Gridner под названием «Конкурентная среда: сетки данных In-Memory». Вы можете увидеть копию по адресу: http://www.gartner.com/technology/reprints.do?id=1-1HCCIMJ&ct=130718&st=sb

Ради полного раскрытия я работаю в Oracle. Мнения и взгляды, выраженные в этом посте, являются моими собственными и не обязательно отражают мнения или взгляды моего работодателя.

...