Apache Ignite vs Oracle СУБД

Apache Ignite – распределенная база данных в памяти, подобные БД получают распространение и хочется сравнить с тем что уже есть и зарекомендовало себя, например реляционная СУБД Oracle. Ignite имеет широкие возможности распределенных вычислений, также есть поддержка SQL на уровне ANSI-99, в производительности SQL и хочется сделать некоторое сравнение. Настройка БД будет в обоих случаях во многом по умолчанию, в случае Oracle это XE, а в случае Ignite это два узла(node) на одном компьютере. Компьютер i5 7400 (4-ядра) 3.5Ггц, 8Гб ОЗУ, SSD диск.
В качестве тестовых данных буду использовать данные КЛАДР (~223 тыс. записей) в качестве среды выполнения запросов DBeaver в котором настроены два подключения к Ignite и Oracle. И первое что сделаю импортирую данные в таблицы, Данные КЛАДР из DBF переведу в CSV, а затем средствами DBeaver выполню импорт в таблицы.

Ignite сконфигурирован так же для хранение данных в постоянном хранилище.
configdefault-config.xml

<!-- Enabling Apache Ignite Persistent Store. -->
        <property name="dataStorageConfiguration">
            <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
                <property name="defaultDataRegionConfiguration">
                    <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
                        <property name="persistenceEnabled" value="true"/>
                    </bean>
                </property>
            </bean>
        </property>	

Структура таблицы Kladr

CREATE TABLE Kladr (
  NAME VARCHAR, 
  CODE VARCHAR,
  SOCR varchar,
  INDEX VARCHAR, PRIMARY KEY (CODE))
  WITH "affinityKey=CODE";  

affinityKey=CODE — означает что данные в Ignite будут распределены по partition и еще распределены по двум узлам. Два узла обеспечены запуском двух экземпляров Ignite.
Еще одна не большая таблица SOCRBASE, это справочник сокращений, у него другое правило хранения в распределенной сети.

CREATE TABLE Socrbase (
  LEVEL LONG, 
  SCNAME VARCHAR,
  SOCRNAME VARCHAR,
  KOD_T_ST LONG,
  PRIMARY KEY (KOD_T_ST))    
  WITH "template=replicated";  

WITH «template=replicated» — таблица будет в полном объеме на каждом узле. Тогда каждый узел когда получив join запрос сможет соединить свои данные с этим справочником, при другой модели хранения нужно было бы обеспечить согласованность partition таблиц.

Вот запущенные две node
первая:

вторая:

Для Orcale структура та же, за исключением partition.

Persistent — хранилище Ignite на диске выглядит как распределение по партициям (файлам), всего их для каждого узла 1024, т.е. все данные для узла распределены в 1024 блока, причем какие то из них находятся на первом узле, а другие на втором.

Пример одного узла

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

Итак первое — это импорт данных средствами DBeaver из CSV, 223 тыс. записей. Вот первый результат.

Далее выполню несколько несложных запросов на поиск данных для сравнения, за результат буду брать второе выполнение подряд (оно всегда меньше для двух БД).

SELECT * FROM KLADR WHERE code IN 
	(
	  SELECT code FROM KLADR k WHERE k."INDEX" IS NOT NULL limit 100
	)  LIMIT 100;  	

SELECT * FROM KLADR WHERE name IN 
	(
	  SELECT name FROM KLADR k limit 100
	) LIMIT 100;  	

SELECT count(*) FROM KLADR WHERE CODE like '02%'

SELECT SUBSTR(k.code, 1, 2), count(k.code) FROM KLADR k 
GROUP BY SUBSTR(k.code, 1, 2)
HAVING count(k.code) > 1000
ORDER BY SUBSTR(k.code, 1, 2)

SELECT k.* FROM KLADR k
 JOIN SOCRBASE s ON k.SOCR = s.SCNAME
WHERE s."LEVEL" = 1 LIMIT 100; 

SELECT s."LEVEL", count(k.code) FROM KLADR k
 JOIN SOCRBASE s ON k.SOCR = s.SCNAME
GROUP BY s."LEVEL";

Да в последнем случае именно 13 сек. показал Ignite запрос, что то с join не все хорошо, правда введение условия ограничивающего данные, уменьшает это время.

Наверное этих сравнений достаточно, не буду делать пока вывод, продолжу изучение Ignite…

Материалы:

Ignite
Getting Started
Getting Started SQL

Автор: Александр

Источник