Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
Статья выглядит несколько странной, если честно.
1)
Почему не третье? Не десятое? Что вы тут хотите проверять: на сколько хорошо данные в кэш попадают, или скорость выполнения запросов?
2)
Так а зачем замерять скорость записи с помощью какого-то стороннего инструмента? У нас есть гарантии, что данные для обоих случаев вставляются одинаково? А не, например, в оракле батчем, а в Игнайте — строка за строкой.
3) Какая цель сравнения инструментов? Оракл — один из лидеров классических персистентных RDBMS. В игнайте SQL-интерфейс добавлен, как маркетинговая фича, и вообще это инмемори кэш, который (как и его конкурент Hazelcast) может персистить данные.
1)
за результат буду брать второе выполнение подряд (оно всегда меньше для двух БД).
Почему не третье? Не десятое? Что вы тут хотите проверять: на сколько хорошо данные в кэш попадают, или скорость выполнения запросов?
2)
Итак первое — это импорт данных средствами DBeaver из CSV, 223 тыс. записей.
Так а зачем замерять скорость записи с помощью какого-то стороннего инструмента? У нас есть гарантии, что данные для обоих случаев вставляются одинаково? А не, например, в оракле батчем, а в Игнайте — строка за строкой.
3) Какая цель сравнения инструментов? Оракл — один из лидеров классических персистентных RDBMS. В игнайте SQL-интерфейс добавлен, как маркетинговая фича, и вообще это инмемори кэш, который (как и его конкурент Hazelcast) может персистить данные.
Изучение нового похвально.
Но подход к оценке и сравнению решений — очень недальновиден. Основная ниша Ignite — обработка и хранение данных, которые физически лежат на большом количестве узлов. Это примерно как сравнивать git и google drive. И тот и другой можно в общем случае использовать для архивирования локальных файлов и истории изменений.
Но подход к оценке и сравнению решений — очень недальновиден. Основная ниша Ignite — обработка и хранение данных, которые физически лежат на большом количестве узлов. Это примерно как сравнивать git и google drive. И тот и другой можно в общем случае использовать для архивирования локальных файлов и истории изменений.
меня и настораживает что как раз Ignite пытаются использовать как SQL БД, это видимо не лучшая его сторона
Собственно дело не в SQL (это просто полезная возможность). Ignite ориентирован на хорошую масштабируемость пропускной способности при обработке больших объёмов данных. Как правило, в тех случаях, когда не требуется хорошее время отклика (которое вы как раз меряете). Oracle пытается оптимизировать и то и другое, но больше всё таки про время отклика. Ну и конфигурация. 2 узла на одной машине — это просто чтобы посмотреть что оно работает. Мерять в такой конфигурации производительность — немножко странно.
Было бы гораздо интереснее посмотреть на тест, построенный таким образом, чтобы Ignite обрабатывал данные быстрее чем Oracle (пусть даже XE без партиционирования).
Было бы гораздо интереснее посмотреть на тест, построенный таким образом, чтобы Ignite обрабатывал данные быстрее чем Oracle (пусть даже XE без партиционирования).
не было задачи сравнивать в полном объеме, т.к. действительно задачи решают они разные
было бы интересно почитать что там реально выходит с персистент на тему сбоев. все ли как в документации и презенташках. на сколько можно положиться на сохранность
Цитата «Настройка БД будет в обоих случаях во многом по умолчанию»
Ваши тесты лишь говорят что настройки по умолчанию у Оракла более оптимальны чем у такие же настройки у Ignite. Не более того.
Ваши тесты лишь говорят что настройки по умолчанию у Оракла более оптимальны чем у такие же настройки у Ignite. Не более того.
Посмотрите раздел документации Ignite Production Tuning. В случае с хранением данных на диске значение имеет, к тому же, файловая система. Например, в моих тестах разница между NTFS и EXT4 была более чем на порядок.
Ignite в роли хранилища использует www.h2database.com и именно его вы сравниваете с Oracle. Это как выставить против Клично 12-летнего подростка.
В H2 очень слабый SQL-движок, вплоть до того, что в джойне с двумя таблицами крайне важно какая таблица стоит после from, а какая после join — в результате разный план и катастрофически разное время исполнения.
В H2 очень слабый SQL-движок, вплоть до того, что в джойне с двумя таблицами крайне важно какая таблица стоит после from, а какая после join — в результате разный план и катастрофически разное время исполнения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apache Ignite vs Oracle СУБД