Я собираюсь попробовать Ignite, чтобы сравнить его с Hazelcast по производительности как сетку данных. Поскольку я изучаю все функции, в которых я нуждаюсь, нет упоминания о дате (java.util.Date) и сравнении String в SQL-запросах (меньше, больше и т. Д.). Я предполагаю, что он полагается на Comparable (я бы) , но хотел бы знать точный ответ.Обработка даты и строк в Ignite SQL-запросах
Другой связанный вопрос (возможно, лучше спрошенный отдельно) касается индексов. Hazelcast имеет индексы и так называемый формат Portable serialization, который по существу хранит подмножество полей отдельно от сериализованного объекта, чтобы избежать десериализации. Как я могу гарантировать, чтобы избежать этого в запросах Ignite SQL? Все поля индексированы? Как насчет составных индексов и т. Д. Мне интересно, как сложные запросы работают внутри страны, поскольку в соответствии с документацией нет составных индексов.
Спасибо. Сканирование кэша, особенно с отражением, не кажется слишком обнадеживающим, но, надеюсь, есть какая-то магия, которая бы побеждала Hazelcast, какие запросы, верьте вам или нет, медленнее, чем на базах данных на диске, например. Монго. Мой одноузловой бенчмарк составляет 100 тыс. Экземпляров. 1K записей фильтруется и упорядочивается одним индексированным полем (со всеми рекомендованными оптимизациями на месте). –
Ignite SQL не использует проверку кеша, если у вас есть правильные индексы. Также отражение в недавней java работает довольно быстро, поэтому не о чем беспокоиться. –
В действительности нет сканирования, поскольку для каждого поля, используемого в запросе SQL, требуется метаданные «поля запроса», которое очень похоже на Hazelcast's Portable, за исключением намного быстрее (за счет памяти, но кто заботится о памяти). Я закончил включение Ignite в Px100 Data (вы можете проверить его на Github - https://github.com/a-rog/px100data), и он работает очень хорошо. Тест приближается. –