Сценарии интеграции приложений. In-Memory Data Grid

231619_0001Пару месяцев назад я написал в FB, что одной из основных технологических тем на ближайший год вижу In-memory data grid (IMDG, распределенные сети данных в памяти). А на днях Gartner порадовал нас новым отчетом Taxonomy, Definitions and Vendor Landscape for In-Memory Computing Technologies (G00254940) в котором попробовал собрать сценарии использования in-memory вычислений и нарисовать список enabler-ов. Получилось у них примерно следующее:

  • Analytical In-Memory DBMS
  • In-Memory DBMS for Transaction Processing
  • In-Memory Data Grids
  • High-Performance Message Infrastructure
  • IM Analytics
  • Complex-Event Processing Platforms
  • In-Memory Application Servers
  • Cloud IMDG Services
  • Cloud Event Processing Services

По-сути, ничего нового. Для всех этих задач всегда использовались дисковые решения, а теперь мы будем их решать при помощи распределенных хранилищ в памяти. Практически все это было сказано в отчете полуторагодовой давности What IT Leaders Need to Know About In-Memory Data Grids (G00231619):

IMDGs help users reduce the cost of running data-intensive, transactional or analytical applications by boosting their scalability and performance, while preserving the integrity of in-memory data

На мой взгляд, действительно интересной темой является изменение технологий интеграции приложений. Если раньше разработчики использовали общую базу данных как основной интеграционный паттерн, то теперь им предстоит сделать тоже самое с распределенным кэшом. И разобраться в этом будет намного сложнее, т.к. во-первых, физическая архитектура IMDG может быть достаточно нетривиальной, а во-вторых, модель данных разработчик придумывает сам (прощай SQL и интерфейсный таблицы, как основной инструмент интеграции). Безусловно, меняется и привычная нам инфраструктура обмена сообщениями (Message Oriented Middleware). W. Roy Schulte пишет о High-Performance Message Infrastructure, которая позволяет:

  • Отправлять приложению более 10000 (persistent) сообщения или 20 Мб данных в секунду с каждого из узлов
  • Доставлять сообщение менее чем за микросекунду если это происходит в одной областипамяти, менее чем за 10 мкс. в кластере с высокоскоростной сетью и менее чем за 50 мкс. в локальной сети или сопоставимой по скорости WAN
  • Создавать системы в архитектуре «публикация-подписка», объединяющие более тысячи узлов продюсеров и подписчиков сообщений

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

Отсутствие стандартов, навыков и передового опыта, а также ограниченность системных интеграторов (SI) и независимых поставщиков программного обеспечения (ISV), станут основными проблемами с которыми мы столкнемся при использовании IMDGs.

Другие статьи по теме:

Реклама

2 responses to “Сценарии интеграции приложений. In-Memory Data Grid

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s