2015-07-17 4 views
2

Я собираюсь попробовать Ignite, чтобы сравнить его с Hazelcast по производительности как сетку данных. Поскольку я изучаю все функции, в которых я нуждаюсь, нет упоминания о дате (java.util.Date) и сравнении String в SQL-запросах (меньше, больше и т. Д.). Я предполагаю, что он полагается на Comparable (я бы) , но хотел бы знать точный ответ.Обработка даты и строк в Ignite SQL-запросах

Другой связанный вопрос (возможно, лучше спрошенный отдельно) касается индексов. Hazelcast имеет индексы и так называемый формат Portable serialization, который по существу хранит подмножество полей отдельно от сериализованного объекта, чтобы избежать десериализации. Как я могу гарантировать, чтобы избежать этого в запросах Ignite SQL? Все поля индексированы? Как насчет составных индексов и т. Д. Мне интересно, как сложные запросы работают внутри страны, поскольку в соответствии с документацией нет составных индексов.

ответ

1

Дата и строка фактически считаются типами SQL TIMESTAMP и VARCHAR соответственно, поэтому речь идет не о Comparable. Но для любых нестандартных типов Ignite SQL будет полагаться на Comparable, если они участвуют в индексах или запросах.

В соответствии с документами поддерживаются индексы, которые называются Group indexes. И сложные запросы работают очень хорошо :)

В настоящее время Ignite не хранит индексированные значения отдельно, а вместо этого сохраняет десериализованный объект Java и использует отражение для доступа к свойствам. В ближайшем будущем (надеюсь, в течение нескольких недель) Ignite собирается выпустить функцию, позволяющую индексировать сериализованные объекты и поля доступа, не сохраняя Java-объекты (или даже индексированные классы Java на узлах).

+0

Спасибо. Сканирование кэша, особенно с отражением, не кажется слишком обнадеживающим, но, надеюсь, есть какая-то магия, которая бы побеждала Hazelcast, какие запросы, верьте вам или нет, медленнее, чем на базах данных на диске, например. Монго. Мой одноузловой бенчмарк составляет 100 тыс. Экземпляров. 1K записей фильтруется и упорядочивается одним индексированным полем (со всеми рекомендованными оптимизациями на месте). –

+0

Ignite SQL не использует проверку кеша, если у вас есть правильные индексы. Также отражение в недавней java работает довольно быстро, поэтому не о чем беспокоиться. –

+0

В действительности нет сканирования, поскольку для каждого поля, используемого в запросе SQL, требуется метаданные «поля запроса», которое очень похоже на Hazelcast's Portable, за исключением намного быстрее (за счет памяти, но кто заботится о памяти). Я закончил включение Ignite в Px100 Data (вы можете проверить его на Github - https://github.com/a-rog/px100data), и он работает очень хорошо. Тест приближается. –