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

Технологии обработки данных в памяти появились не вчера — рост объемов кода и обрабатываемых данных, а также удешевление модулей памяти в свое время подтолкнули разработчиков к созданию решений по кэшированию СУБД. За счет более высокой, по сравнению с дисковыми накопителями, скорости доступа к данным удалось увеличить производительность традиционных реляционных СУБД. Дальнейшие разработки привели к появлению СУБД, для которых оперативная память стала основным устройством хранения, а дисковые накопители используются для обеспечения отказоустойчивости и исключения потерь данных. Сегодня граница между 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 (ADG).

Рис. 1. Принципиальная схема кластера ADG

По аналогии с СУБД Cassandra [1], платформа ADG представляет собой кластер из множества серверов, объединенных в топологию «кольцо» (рис. 1). Клиенты подключаются к кластеру, выполняя поиск по статически заданному списку адресов либо осуществляя широковещательный сетевой поиск узлов. В ADG поддерживается стандарт ANSI 99 SQL, что позволяет приложениям использовать полноценные SQL-запросы при работе с данными в кэше. Кроме того, обеспечивается распределенное объединение таблиц (Distributed Joins), которые выполняются наиболее эффективно для таблиц с разделами, распределенными по узлам кластера для одного из столбцов. В качестве внешнего постоянного хранилища данных могут служить СУБД Oracle, MySQL, PostgreSQL, Microsoft SQL Server, а также некоторые СУБД NoSQL и HDFS. Независимо от используемой СУБД, ADG обеспечит прозрачное выполнение запросов на выполнение операций с единым массивом данных, задействуя всю доступную оперативную память для кэширования данных и обеспечивая консистентное состояние посредством сквозного чтения и записи (read/write through). В реляционных СУБД такие чтение и запись могут осуществляться в рамках транзакций, обеспечивая атомарность операций обновления и вставки.

Применение традиционных СУБД — не единственная возможность избежать потери данных при перезагрузке кластера: в ADG имеется собственное дисковое хранилище Native Persistence, которое «вытесняет» на диск редко используемые данные из кэша и осуществляет бесшовную интеграцию данных на диске и в памяти. Кроме того, Native Persistence позволяет выполнять запросы сразу после старта кластера — не требуется ждать, пока массив данных будет считан из СУБД в память узлов, что обычно невозможно в случае использования сторонних СУБД.

Рис. 2. Интеграция ADG и Arenadata DB

Платформа ADG через фреймворк Greenplum PXF (Platform Extension Framework) интегрируется с массивно-параллельной СУБД Arenadata DB [2] для выполнения многоуровневой обработки данных (рис. 2).

***

Открытая платформа обработки данных в памяти может применяться для ускорения выполнения аналитических действий над оперативными данными в массивно-параллельной СУБД, кэширования оперативных данных в HDFS и реализации транзакционного кэша данных для систем потоковой передачи и шин данных. Поддержка горизонтального масштабирования, ANSI SQL и интеграция ADG с различными СУБД и MPP-системами позволяют применять эту платформу в качестве распределенного кэша данных для корпоративных информационных систем.

Литература

  1. Ганеш Чандра Дека. СУБД NoSQL // Открытые системы.СУБД. — 2014. — № 4. — С. 44–47. URL: www.osp.ru/os/2014/ 04/13041253 (дата обращения: 21.04.2018).
  2. Дмитрий Павлов. Открытая аналитическая СУБД // Открытые системы.СУБД.— 2018. — № 1. — С. 32–33. URL: www.osp.ru/os/2018/01/13053940 (дата обращения: 21.05.2018).

Александр Рындин (ra@arenadata.io) — инженер-разработчик проекта Arenadata, компания IBS (Москва).