08.01.2018 17:26
arylkov 12 4600 Источник
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 сконфигурирован так же для хранение данных в постоянном хранилище.
config\default-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 тыс. записей. Вот первый результат.
Импорт данных 223 тыс. записей (КЛАДР)
Ignite 12 мин Oracle 5 сек.

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

Получить 100 записей КЛАДР по любым 100 CODE, по CODE есть индекс
SELECT * FROM KLADR WHERE code IN 
	(
	  SELECT code FROM KLADR k WHERE k."INDEX" IS NOT NULL limit 100
	)  LIMIT 100;

Ignite 30 мсек. Oracle 6 мсек.


Получить 100 записей КЛАДР по любым 100 NAME, по NAME нет индекса
SELECT * FROM KLADR WHERE name IN 
	(
	  SELECT name FROM KLADR k limit 100
	) LIMIT 100;

Ignite 80 мсек. Oracle 6 мсек.


Посчитать количество субъектов в регионе
SELECT count(*) FROM KLADR WHERE CODE like '02%'

Ignite 30 мсек. Oracle 6 мсек.


Количество субъектов в регионе более 1000
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)

Ignite 150 мсек. Oracle 60 мсек.


Join запрос. Получить 100 субъектов первого уровня
SELECT k.* FROM KLADR k
 JOIN SOCRBASE s ON k.SOCR = s.SCNAME
WHERE s."LEVEL" = 1 LIMIT 100;

Ignite 280 мсек. Oracle 2 мсек.


Join запрос. Количество субъектов на уровнях
SELECT s."LEVEL", count(k.code) FROM KLADR k
 JOIN SOCRBASE s ON k.SOCR = s.SCNAME
GROUP BY s."LEVEL";

Ignite 13 сек. Oracle 140 мсек.

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

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

Материалы:

Ignite
Getting Started
Getting Started SQL

Комментарии (12)


  1. Hixon10
    08.01.2018 21:35
    #10605256

    Статья выглядит несколько странной, если честно.

    1)

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

    Почему не третье? Не десятое? Что вы тут хотите проверять: на сколько хорошо данные в кэш попадают, или скорость выполнения запросов?

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

    Так а зачем замерять скорость записи с помощью какого-то стороннего инструмента? У нас есть гарантии, что данные для обоих случаев вставляются одинаково? А не, например, в оракле батчем, а в Игнайте — строка за строкой.

    3) Какая цель сравнения инструментов? Оракл — один из лидеров классических персистентных RDBMS. В игнайте SQL-интерфейс добавлен, как маркетинговая фича, и вообще это инмемори кэш, который (как и его конкурент Hazelcast) может персистить данные.


    1. arylkov Автор
      09.01.2018 06:33
      #10605586

      Специально сравнивать не было задачи, с Oracle работал с Ignite предстоит, само собой стало интересно как же там будут решаться подобные задачи.


      1. smitevg
        09.01.2018 11:58
        #10605994

        Занимался подобными задачами.
        Сложности в замене Oracle на GridGain
        Самые важные:
        1. Изменение схемы данных
        2. Изменение данных на ПРОДе (как будем менять)
        3. Консистентность. Драматичная просадка производительности при ее гарантировании. Но это не точно.


  1. ggo
    09.01.2018 09:38
    #10605696

    Изучение нового похвально.
    Но подход к оценке и сравнению решений — очень недальновиден. Основная ниша Ignite — обработка и хранение данных, которые физически лежат на большом количестве узлов. Это примерно как сравнивать git и google drive. И тот и другой можно в общем случае использовать для архивирования локальных файлов и истории изменений.


    1. arylkov Автор
      09.01.2018 10:31
      #10605782

      меня и настораживает что как раз Ignite пытаются использовать как SQL БД, это видимо не лучшая его сторона


      1. GlukKazan
        09.01.2018 11:26
        #10605884

        Собственно дело не в SQL (это просто полезная возможность). Ignite ориентирован на хорошую масштабируемость пропускной способности при обработке больших объёмов данных. Как правило, в тех случаях, когда не требуется хорошее время отклика (которое вы как раз меряете). Oracle пытается оптимизировать и то и другое, но больше всё таки про время отклика. Ну и конфигурация. 2 узла на одной машине — это просто чтобы посмотреть что оно работает. Мерять в такой конфигурации производительность — немножко странно.

        Было бы гораздо интереснее посмотреть на тест, построенный таким образом, чтобы Ignite обрабатывал данные быстрее чем Oracle (пусть даже XE без партиционирования).


        1. arylkov Автор
          09.01.2018 11:55
          #10605980

          Ок, спасибо, надо подумать )


  1. arylkov Автор
    09.01.2018 10:28
    #10605778

    не было задачи сравнивать в полном объеме, т.к. действительно задачи решают они разные


  1. Yo1
    09.01.2018 15:07
    #10606360
    +1

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


  1. Andronas
    09.01.2018 22:25
    #10607258

    Цитата «Настройка БД будет в обоих случаях во многом по умолчанию»

    Ваши тесты лишь говорят что настройки по умолчанию у Оракла более оптимальны чем у такие же настройки у Ignite. Не более того.


  1. vdshat
    09.01.2018 23:31
    #10607348

    Посмотрите раздел документации Ignite Production Tuning. В случае с хранением данных на диске значение имеет, к тому же, файловая система. Например, в моих тестах разница между NTFS и EXT4 была более чем на порядок.


    1. arylkov Автор
      11.01.2018 07:52
      #10609330

      Ок, интересно