Apache Ignite 2.1 — теперь со вкусом Persistence

МЕНЮ


Искусственный интеллект. Новости
Поиск

ТЕМЫ


Внедрение ИИНовости ИИРобототехника, БПЛАТрансгуманизмЛингвистика, обработка текстаБиология, теория эволюцииВиртулаьная и дополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информации

RSS


RSS новости

Авторизация



Новостная лента форума ailab.ru

В конце июля вышла версия Apache Ignite 2.1. Apache Ignite — распределенная свободная HTAP-платформа (HTAP — Hybrid Transactional and Analytical Processing, системы, которые могут обрабатывать как транзакционную, так и аналитическую нагрузку) для хранения данных в оперативной памяти и на диске, а также вычислений в реальном времени. Ignite написан на Java и может быть плотно интегрирован с .NET и C++.

Версия 2.1 очень богата на значимые, практически применимые функции, базирующиеся на фундаменте, заложенном в Apache Ignite 2.0.

С Apache Ignite 2.1 можно использовать распределенное дисковое хранилище Apache Ignite Persistent Data Store с поддержкой SQL, первые распределенные алгоритмы машинного обучения, новые функции DDL, и кроме того значительно улучшена поддержка платформ .NET и C++.

Persistent Data Store выводит Apache Ignite в новый сегмент — теперь это не просто in-memory data grid, но полноценная распределенная масштабируемая база данных HTAP с возможностью надежного хранения первичных данных, с поддержкой SQL и обработкой информации в реальном времени.

Apache Ignite PDS — Persistence Data Store

Persistence Data Store — новый компонент платформы, который позволяет использовать для хранения данных не только RAM, но и диск.
Мы вложили столько труда программистов в разработку PDS из-за ограничений классических сторонних СУБД при использовании их в связке с системами, подобными Apache Ignite.

  1. СУБД — узкое место при сохранении данных. С помощью технологий вычисления в памяти и горизонтального масштабирования можно добиться значительно более высоких показателей чтения данных. Но при этом запись останется узким местом, поскольку платформе нужно будет дублировать операции записи в СУБД, которая почти всегда масштабируется намного хуже, если масштабируется вообще.?? А потребность в быстрой записи иногда может быть выше потребности в быстром чтении. Например, у одного из наших клиентов лишь несколько десятков запросов на чтение в секунду (нужна очень низкая задержка отдачи данных при произвольном чтении), и одновременно с этим десятки тысяч операций записи в секунду, которые необходимо транзакционно сохранить для последующего доступа.
  2. СУБД — единая точка отказа. Кластеры Apache Ignite могут состоять из десятков и сотен узлов, которые резервируют друг друга, обеспечивая безопасность клиентских данных и операций. При этом СУБД в большинстве случаев имеет намного более ограниченные возможности резервирования.?? Падение СУБД в такой ситуации обойдётся гораздо дороже, станет бОльшим стрессом для компании, чем падение одного или нескольких узлов кластера.
  3. Невозможность одновременно выполнять SQL поверх данных в Ignite и в СУБД. Вы можете выполнять запросы ANSI SQL 99 поверх данных, хранящихся в памяти кластера Apache Ignite, но не можете корректно выполнять подобные запросы, если хотя бы часть данных находится внутри сторонней СУБД.?? Причина: Apache Ignite не контролирует эту СУБД и не знает, какие данные находятся в ней, а какие нет. Пессимистичная гипотеза, что не все данные находятся в RAM, привела бы к необходимости дублировать каждый запрос в СУБД, что значительно снизило бы производительность (не говоря о необходимости интегрирования со множеством SQL- и NoSQL-решений, каждое из которых имеет свои особенности и ограничения работы с данными, что фактически невыполнимая задача!).
  4. Необходимость прогрева. Чтобы воспользоваться Apache Ignite, нужно сначала загрузить необходимые данные из СУБД в кластер, что при больших объемах данных может занимать колоссальное время. Представьте, сколько будет загружаться в кластер, например, 4 терабайта данных! ??Apache Ignite не может делать это по мере необходимости без дополнительной, написанной со стороны пользователя логики по тем же причинам, что и в предыдущем пункте.

Реализация PDS позволила нам организовать распределенное, горизонтально масштабируемое хранилище, которое ограничено по объему в первую очередь доступными физическими дисковыми массивами, и которое решает описанные выше проблемы.

  1. PDS масштабируется вместе с кластером. Каждый узел Apache Ignite теперь хранит свой участок данных не только в памяти, но и на диске. Это дает близкую к линейной масштабируемость по производительности операций записи.
  2. PDS поддерживает механизмы отказоустойчивости Apache Ignite. Для эффективного распределения и резервирования данных вы можете использовать тот же коэффициент избыточности и функцию колокации. Проприетарный модуль GridGain также позволит делать резервные online-копии всего дискового пространства. Их можно использовать для последующего восстановления после аварий (DR), либо развернуть на другом кластере, в том числе меньшего размера, для не-real-time аналитики, которая могла бы слишком загрузить основной кластер.
  3. PDS позволяет выполнять SQL-запросы применительно к данным как в памяти, так и на диске. Поскольку Apache Ignite тесно интегрирован с этим хранилищем, платформа имеет исчерпывающую информацию по месторасположению данных и может выполнять «сквозные» SQL-запросы. За счет этого пользователь получает возможность использовать Apache Ignite как Data Lake — хранить большой архив информации, который будет лежать на диске, и при необходимости выполнять запросы с учетом этой информации.
  4. PDS позволяет использовать “lazy run” — загружать данные в память постепенно, по мере необходимости. В таком случае кластер может стартовать практически мгновенно, вхолодную, и по мере обращений к данным они будут постепенно переноситься в RAM. Это позволяет значительно ускорить восстановление после аварии (DR RTO), уменьшает риски для бизнеса, а также облегчает и удешевляет процедуры тестирования и разработки за счет экономии времени на прогреве.

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

Технические детали

Взаимодействие между памятью и диском основано на технологиях, реализованных в Apache Ignite 2.0. Доступное пространство хранения делится на страницы, каждая из которых может содержать 0 и более объектов, либо участок объекта (в тех случаях, когда объект превышает страницу по объему). Страница может располагаться в оперативной памяти с дублированием на диске, либо только на диске.

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

Индексы лежат на отдельных страницах, и при грамотно построенных запросах поиск должен идти по данным в индексах, которые содержаться в памяти, чтобы избежать полного сканирования и последовательного поднятия всего массива информации с диска.

Persistence Data Store очень легко включить:

<bean id="ignite.cfg"       class="org.apache.ignite.configuration.IgniteConfiguration">     <!-- … -->     <property name="persistentStoreConfiguration">         <bean class="org.apache.ignite.configuration.PersistentStoreConfiguration"/>     </property>     <!-- … --> </bean> 

или

igniteConfiguration.setPersistentStoreConfiguration(     new PersistentStoreConfiguration()); 

Важно! При этом поменяется процедура запуска кластера. После старта всех узлов будет необходимо будет активировать кластер, например, в web-консоли, либо вызвав ignite.activate(true) в коде. Это необходимо для того, чтобы убедиться, что все узлы, которые хранят в себе информацию, вошли в строй и готовы работать со своей частью набора данных. В ином случае кластер считал бы, что часть первичных или резервных копий данных отсутствует и начал бы ребалансировку (перераспределение копий данных между узлами, чтобы обеспечить необходимый уровень резервирования и равномерность распределения нагрузки), что не является желаемым поведением.

Резюмируя, Persistent Data Store выводит Apache Ignite в новый сегмент, позволяя пользователям использовать Ignite не только как систему обработки данных, но и как горизонтально масштабируемый слой первичного хранения.

Алгоритмы машинного обучения

В Apache Ignite 2.1 появились первые практически применимые распределенные алгоритмы машинного обучения, основанные на технологиях Apache Ignite 2.0кластеризация методом k-средних (k-means) и множественная линейная регрессия методом наименьших квадратов.

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

Пример применения (Java)

KMeansLocalClusterer clusterer =     new KMeansLocalClusterer(new EuclideanDistance(), 1, 1L);  double[] v1 = new double[] {1959, 325100}; double[] v2 = new double[] {1960, 373200};  DenseLocalOnHeapMatrix points =     new DenseLocalOnHeapMatrix(new double[][] {v1, v2});  KMeansModel mdl = clusterer.cluster(points, 1);  Integer clusterInx =     mdl.predict(         new DenseLocalOnHeapVector(new double[] {20.0, 30.0})); 

Моделью распределения данных можно управлять, используя разные реализации матриц и векторов. Так DenseLocalOnHeapMatrix использует хранение данных только на локальном узле в управляемой куче JVM.

DDL

В Apache Ignite 2.1 расширена поддержка DDL. Если в Apache Ignite 2.0 появилась работа с индексами, то новая версия даёт возможность работать с таблицами: CREATE TABLE и DROP TABLE.

CREATE TABLE IF NOT EXISTS Person (   age int, id int, name varchar, company varchar,   PRIMARY KEY (name, id))   WITH "template=replicated,backups=5,affinitykey=id";  DROP TABLE Person; 

Таблицы создаются в схеме PUBLIC, для каждой из них создается новый кеш. Таблицы имеют дополнительные настройки, которые можно задавать в разделе WITH:

  • TEMPLATE — основать кеш данной таблицы на указанном кеше, имеются специальные значения PARTITIONED и REPLICATED, которые указывают использовать настройки по умолчанию и соответствующую модель распределения кеша.
  • BACKUPS — количество резервных копий данных — коэффициент избыточности.
  • ATOMICITY — может принимать значения ATOMIC и TRANSACTIONAL, то есть включает или выключает транзакционность на данном кеше.
  • CACHEGROUP — группа, к которой принадлежит кеш.
  • AFFINITYKEY — имя колонки (обязательно должна быть частью PRIMARY KEY!), которую следует использовать как ключ партиционирования для корректной колокации данных.

В будущих релизах планируется добавить возможность задавать колонки как NOT NULL, указывать значения по-умолчанию, параметр AUTO INCREMENT и т.д., а также хотим расширять словарь DDL-выражений.

Группы кешей

В Apache Ignite 2.1 появилась возможность использовать группы кешей, которые делят внутри себя общее хранилище, партиции, позволяя при этом хранить различные виды значений. Этот подход позволяет значительно сократить накладные расходы на заведение большого количества кешей как с точки зрения необходимого пространства в памяти, так и с точки зрения процессорных ресурсов на ведение и синхронизацию информации по этим кешам.

При этом такие группы будут иметь общий физический кеш, соответственно, и такие его компоненты как affinity-функцию, node filter, режим работы кеша, политику обработки потери партиций, политику утилизации памяти.

И многое другое


Источник: habrahabr.ru