Тест Hazelcast против Ignite

Question

Я использую сетки данных как свою основную «базу данных». Я заметил резкую разницу между производительностью запросов Hazelcast и Ignite. Я оптимизировал использование своей сетки данных с помощью собственной пользовательской сериализации и индексов, но разница по-прежнему заметна.

Поскольку никто не спросил его здесь, я собираюсь ответить на свой вопрос для всех будущих ссылок. Это не абстрактное (учебное) упражнение, а реальный тест, который моделирует использование моей сетки данных в больших системах SaaS - в первую очередь для отображения отсортированных и фильтрованных разбитых на страницы списков. Я прежде всего хотел знать, сколько накладных расходов мой универсальный уровень доступа к сетям данных JDBC-ish добавляется по сравнению с необработанными без рамки использования Hazelcast и Ignite. Но поскольку я сравниваю яблоки с яблоками, здесь идет эталон.

Answer 1

Вот тест исходный код: https://github.com/a-rog/px100data/tree/master/examples/HazelcastVsIgnite

Это является частью JDBC-иш рамках NoSQL я уже говорил ранее: Px100 Data

здания и запустить его:

cd <project-dir> 
mvn clean package 
cd target 
java -cp "grid-benchmark.jar:lib/*" -Xms512m -Xmx3000m -Xss4m com.px100systems.platform.benchmark.HazelcastTest 100000 
java -cp "grid-benchmark.jar:lib/*" -Xms512m -Xmx3000m -Xss4m com.px100systems.platform.benchmark.IgniteTest 100000 

Как вы можете см., я установил максимальные пределы памяти, чтобы избежать сбора мусора. Вы также можете запустить мой собственный тест framework (см. Px100DataTest.java) и сравнить его с двумя выше, но давайте сосредоточимся на чистой производительности. Ни один из тестов не использует Spring или что-либо еще, кроме Hazelcast 3.5.1 и Ignite 1.3.3 - последнего на данный момент.

Контрольный номер транзакции вставляется указанное количество экземпляров. Записи размером 1 КБ (100000 из них - вы можете увеличить его, но остерегайтесь памяти) партиями (транзакциями) 1000. Затем он выполняет два запроса с восходящей и нисходящей сортировкой: четыре всего. Все поля запроса и ORDER BY индексируются.

Я не собираюсь публиковать весь класс (скачать его из GitHub). Запрос Hazelcast выглядит следующим образом:

PagingPredicate predicate = new PagingPredicate(
     new Predicates.AndPredicate(new Predicates.LikePredicate("textField", "%Jane%"), 
      new Predicates.GreaterLessPredicate("id", first.getId(), false, false)), 
     (o1, o2) -> ((TestEntity)o1.getValue()).getId().compareTo(((TestEntity)o2.getValue()).getId()), 
     100); 

Совпадение Ignite запрос:

SqlQuery<Object, TestEntity> query = new SqlQuery<>(TestEntity.class, 
     "FROM TestEntity WHERE textField LIKE '%Jane%' AND id > '" + first.getId() + "' ORDER BY id LIMIT 100"); 
    query.setPageSize(100); 

Вот результаты выполнены на моем 2012 8-ядерный MBP с 8G памяти:

Hazelcast

Starting - used heap: 49791048 bytes 
Inserting 100000 records: .................................................................................................... 
Inserted all records - used heap: 580885264 bytes 
Map: 100000 entries, used heap: 531094216 bytes, inserts took 5458 ms 
Query 1 count: 100, time: 344 ms, heap size: 298844824 bytes 
Query 2 count: 100, time: 115 ms, heap size: 454902648 bytes 
Query 3 count: 100, time: 165 ms, heap size: 657153784 bytes 
Query 4 count: 100, time: 106 ms, heap size: 811155544 bytes 

Ignite

Starting - used heap: 100261632 bytes 
Inserting 100000 records: .................................................................................................... 
Inserted all records - used heap: 1241999968 bytes 
Cache: 100000 entries, heap size: 1141738336 bytes, inserts took 14387 ms 
Query 1 count: 100, time: 222 ms, heap size: 917907456 bytes 
Query 2 count: 100, time: 128 ms, heap size: 926325264 bytes 
Query 3 count: 100, time: 7 ms, heap size: 926325264 bytes 
Query 4 count: 100, time: 103 ms, heap size: 934743064 bytes 

Одна очевидная разница в производительности вставки - заметно в реальной жизни. Однако очень редко одна вставка 1000 записей. Обычно это одна вставка или обновление (сохранение введенных данных пользователя и т. Д.), Поэтому меня это не беспокоит. Однако производительность запросов. Большинство бизнес-приложений, ориентированных на данные, отличаются прочностью.

Обратите внимание на потребление памяти. Ignite намного более голоден, чем Hazelcast. Это может объяснить лучшую производительность запросов. Ну, если я решил использовать сетку в памяти, я должен беспокоиться о памяти?

Вы можете четко сказать, когда сетки данных попадают в индексы, а когда нет, как они кэшируют скомпилированные запросы (7 мс) и т. Д. Я не хочу спекулировать и позволяю вам играть с ним, а также , поскольку разработчики Hazelcast и Ignite предоставляют некоторое представление.

Насколько это возможно, это сопоставимо, если не ниже MySQL. Технология IMO в памяти должна улучшиться. Я уверен, что обе компании будут делать заметки.

Результаты, приведенные выше, довольно близки. Однако при использовании в Px100 Data и более высоком уровне Px100 (который сильно зависит от индексированных полей сортировки для разбивки на страницы) Ignite выдвигается вперед и лучше подходит для моей структуры. В первую очередь я забочусь о производительности запросов.

Answer 2

Я рассмотрел предоставленный код на GitHub и имею много комментариев:

индексирования и присоединяется

1. Вероятно, наиболее важным моментом является то, что Apache Ignite индексации является гораздо более сложным, чем Hazelcast. В отличие от Hazelcast, Ignite поддерживает ANSI 99 SQL, поэтому вы можете писать свои запросы по своему усмотрению.
2. Самое главное, в отличие от Hazelcast, Ignite поддерживает групповые индексы и SQL JOINs в разных кешах или типах данных. Представьте, что у вас есть персональные и организационные таблицы, и вам нужно выбрать всех лиц, работающих в той же Организации. Это невозможно сделать в 1 шаг в Hazelcast (исправьте меня, если я ошибаюсь), но в Ignite это простой запрос SQL JOIN.

Учитывая вышеизложенное, индексы Ignite займут немного больше времени, особенно в вашем тесте, где у вас есть 7 из них.

Исправления в TestEntity класса

В вашем коде, объект хранить в кэше, TestEntity, пересчитывает значение для idSort, createdAtSort и modifiedAtSort каждый раз, когда геттер называется. Ignite вызывает эти геттеры несколько раз, пока объект хранится в дереве индексов. Простое исправление к классу TestEntity обеспечивает повышение производительности 4x: https://gist.github.com/dsetrakyan/6bfe089d53f888448503

Heap измерение не является точной

Пути вы измеряете кучи неверны. Вы должны хотя бы позвонить System.gc() перед тем, как принять измерение кучи, и даже это будет неточно. Например, в приведенных ниже результатах я получаю отрицательный размер кучи, используя ваш метод.

Warmup

Каждый тест требует разминку. Например, когда я применяю исправление TestEntity, как было предложено выше, а количество пользователей и запросов кэша 2 раза, я получаю лучшие результаты.

MySQL Сравнение

Я не думаю, что сравнение тест сетки данных одного узла к MySQL является справедливым, ни для Ignite, ни для Hazelcast. Базы данных имеют собственное кэширование, и при работе с такими небольшими объемами памяти вы обычно проверяете кеш-память в кэш-памяти базы данных и кэширование данных в сетке данных.

Преимущества производительности обычно возникают при выполнении распределенного теста по секционированному кешу. Таким образом, Data Grid будет выполнять запрос на каждом узле кластера параллельно, и результаты должны возвращаться намного быстрее.

Результаты

Вот результаты, которые я получил для Apache Ignite. Они выглядят намного лучше после того, как я сделал вышеупомянутые исправления.

Обратите внимание, что во второй раз, когда мы выполняем запросы кэш-памяти и кеш-запросы, мы получаем лучшие результаты, потому что JVM HotSpot разогревается.

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

[00:45:15] Ignite node started OK (id=0960e091, grid=Benchmark) 
[00:45:15] Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, heap=8.0GB] 
Starting - used heap: 225847216 bytes 
Inserting 100000 records: .................................................................................................... 
Inserted all records - used heap: 1001824120 bytes 
Cache: 100000 entries, heap size: 775976904 bytes, inserts took 14819 ms 
------------------------------------ 
Starting - used heap: 1139467848 bytes 
Inserting 100000 records: .................................................................................................... 
Inserted all records - used heap: 978473664 bytes 
Cache: 100000 entries, heap size: **-160994184** bytes, inserts took 11082 ms 
------------------------------------ 
Query 1 count: 100, time: 110 ms, heap size: 1037116472 bytes 
Query 2 count: 100, time: 285 ms, heap size: 1037116472 bytes 
Query 3 count: 100, time: 19 ms, heap size: 1037116472 bytes 
Query 4 count: 100, time: 123 ms, heap size: 1037116472 bytes 
------------------------------------ 
Query 1 count: 100, time: 10 ms, heap size: 1037116472 bytes 
Query 2 count: 100, time: 116 ms, heap size: 1056692952 bytes 
Query 3 count: 100, time: 6 ms, heap size: 1056692952 bytes 
Query 4 count: 100, time: 119 ms, heap size: 1056692952 bytes 
------------------------------------ 
[00:45:52] Ignite node stopped OK [uptime=00:00:36:515] 

Я создам еще один репо GitHub с исправленным кодом и разместить его здесь, когда я больше бодрствует (кофе не помогает больше).