Apache Ignite: How does indexing work?

Question

How does Apache Ignite indexing work? I did not find these technical details in the documentation.

• Is this a B-tree used?
• Where is the index stored?
• How is it stored?
• What performance (in Big-O notation) does the post-build index provide in use?
• How fast is it created when it is created?
• Ignite can store arbitrary serializable Java objects. How does this relate to composites when I want to index a sub-object field?
• Ignite Cache is a keystore. Can I have different classes (= types as objects) as values? In other words, is this an Ignite Cache Schemaless schema? If so, how does this match my SQL queries?
• Ignite Cache is a keystore. How do keys come into play if I have a SQL query for my values? What am I asking for?
• The keys can be arbitrary, serializable Java objects - can I ask for keys or just values?

Answer 1

This information is not considered very strongly in the documents, since it is mainly an implementation detail and can change from version to version. After all, the source code is available if you are interested in the details. To be specific, I'm talking about Ignite 1.5, which will be released soon.

• Prior to 1.5, the default data structure was a snap-in (the avl-tree option), since the 1.5 skip-list option was added, and now it is the default.
• In java heap or in heap memory depending on configuration.
• Reliable :) I do not understand this question.
• log (N) when updating and searching.
• The index is updated with every transactional commit (or just update the cache in the case of the atomic cache), there is no separate build phase. You can expect the indexes to be in the correct state after each update.
• Ignite has two options (starting with 1.5): either store objects in binary format, which allows you to get individual field values ​​or keep the entire object deserialized and use reflection.
• and etc.

Good luck