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

Apache Ignite PDS — Persistence Data Store

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

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), уменьшает риски для бизнеса, а также облегчает и удешевляет процедуры тестирования и разработки за счет экономии времени на прогреве.

<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()); 

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

Пример применения (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})); 

DDL

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; 

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

Группы кешей

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

• Переработан и оптимизирован тонкий JDBC-драйвер
• .NET — поддержка DML через LINQ
• C++ — начальная поддержка распределенных вычислений на C++