Реклама

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

Технологии обработки данных в памяти появились не вчера — рост объемов кода и обрабатываемых данных, а также удешевление модулей памяти в свое время подтолкнули разработчиков к созданию решений по кэшированию СУБД. За счет более высокой, по сравнению с дисковыми накопителями, скорости доступа к данным удалось увеличить производительность традиционных реляционных СУБД. Дальнейшие разработки привели к появлению СУБД, для которых оперативная память стала основным устройством хранения, а дисковые накопители используются для обеспечения отказоустойчивости и исключения потерь данных. Сегодня граница между in-memory и традиционными СУБД постепенно размывается — в последних все активнее для ускорения доступа используется оперативная память. Вместе с тем бизнес-приложениям может потребоваться максимально быстрый кэшируемый доступ к данным, в угоду которому жертвуют SQL-запросами, отказавшись от реляционных СУБД. Но тогда нужны системы хранения в памяти пар «ключ-значение» — СУБД in-memory key-value, реализующие максимально простой интерфейс доступа к данным и предоставляющие разработчику возможность записывать и считывать по ключу сериализованное представление объекта. Одна из самых известных систем такого класса — СУБД Redis, использование которой в качестве кэширующего уровня хранения в памяти позволяет значительно увеличить производительность приложения, снизив нагрузку на основное хранилище данных. Однако в этом случае на разработчика ложится ответственность за синхронизацию и актуализацию данных в кэше — Redis лишь ограниченно поддерживает синхронизацию данных в кэше с данными в традиционной СУБД. Задача еще усложняется, если реализовывать кэш нужно одновременно для нескольких приложений, и становится практически невыполнимой, если при этом еще требуется обеспечить горизонтальное масштабирование.

В ответ на эти требования появились «умные» распределенные системы хранения в памяти In-memory Data Grid (IMDG), в которых данные распределяются особым образом и хранятся в памяти узлов кластера. Разработчик по-прежнему может записывать и считывать данные по ключу, используя популярные протоколы доступа, например Java API или HTTP REST, но при этом данные в кэше всегда будут синхронизированы с нижележащей базой данных. Кроме того, в IMDG реализуется концепция аренды ресурсов и совместной обработки (colocated processing), напоминающая MapReduce. Данные, хранящиеся на узлах IMDG-кластера, там же и обрабатываются, что позволяет задействовать вычислительные мощности узлов хранения данных и снизить нагрузку на сеть. Это выгодно отличает IMDG от таких систем, как Memcached и Redis Distributed.

Для решения ряда задач может быть вполне достаточно возможностей, предоставляемых такими IMDG-системами, как Hazelcast или Gemfire, — они позволяют множеству различных приложений использовать единый распределенный кэш «ключ-значение», а при необходимости можно подгружать данные из сторонних СУБД c поддержкой синхронизированности. Однако часто этого мало: для реальных прикладных бизнес-задач требуются полноценная поддержка SQL, ACID и быстрое восстановление данных в памяти при рестарте узлов кластера, а этого IMDG предоставить не может.

Попытки исправить недостатки IMDG привели к появлению более совершенного класса систем обработки данных — In-memory Computing Platforms. Одним из примеров таких систем стала основанная на Apache Ignite аппаратно-программная платформа обработки данных в памяти — Arenadata Grid...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF