Как стать автором
Обновить

Комментарии 14

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

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

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

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

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

3) Какая цель сравнения инструментов? Оракл — один из лидеров классических персистентных RDBMS. В игнайте SQL-интерфейс добавлен, как маркетинговая фича, и вообще это инмемори кэш, который (как и его конкурент Hazelcast) может персистить данные.
Специально сравнивать не было задачи, с Oracle работал с Ignite предстоит, само собой стало интересно как же там будут решаться подобные задачи.
Занимался подобными задачами.
Сложности в замене Oracle на GridGain
Самые важные:
1. Изменение схемы данных
2. Изменение данных на ПРОДе (как будем менять)
3. Консистентность. Драматичная просадка производительности при ее гарантировании. Но это не точно.

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

Было бы гораздо интереснее посмотреть на тест, построенный таким образом, чтобы Ignite обрабатывал данные быстрее чем Oracle (пусть даже XE без партиционирования).
Ок, спасибо, надо подумать )
не было задачи сравнивать в полном объеме, т.к. действительно задачи решают они разные
было бы интересно почитать что там реально выходит с персистент на тему сбоев. все ли как в документации и презенташках. на сколько можно положиться на сохранность
Цитата «Настройка БД будет в обоих случаях во многом по умолчанию»

Ваши тесты лишь говорят что настройки по умолчанию у Оракла более оптимальны чем у такие же настройки у Ignite. Не более того.
Посмотрите раздел документации Ignite Production Tuning. В случае с хранением данных на диске значение имеет, к тому же, файловая система. Например, в моих тестах разница между NTFS и EXT4 была более чем на порядок.
Ок, интересно
Ignite в роли хранилища использует www.h2database.com и именно его вы сравниваете с Oracle. Это как выставить против Клично 12-летнего подростка.

В H2 очень слабый SQL-движок, вплоть до того, что в джойне с двумя таблицами крайне важно какая таблица стоит после from, а какая после join — в результате разный план и катастрофически разное время исполнения.
ок. все познается в сравнении )
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории