Yes. there are scenarios you can't use simple data types. This relates to
not only Ignite.
As Ignite SQL layer is built over key-value storage, there always be some
overhead on SQL operations.
Key-value API allow you operate with one or more cache entries with known
keys.
If the keys of entries
But you cannot use simple datatypes all the time in a real scenario, right? I
mean when you need to get results based on multiple fields/columns [unless I
form a key or something based on them]
As per different discussions here in the forum and from some demo stubs, I
understand performance of
Hi,
1. Yes, use simple types if it is possible. These types has much smaller
footprint than POJOs. Ignite has performance optimization for simple types
(and some other JDK classes like String).
Ignite use BinaryObjects [1] concept that allows to query certain
user-object's field without
Hi Andrew,
Thanks for the reply.
I have two more doubts:
1. So rather than a Custom key, you are suggesting to use simple types like
Integer, Long, etc, right? Why is this so?
2. What does indices with proper inline size mean ? Also, more indices does
not necessarily give better performance
Hi,
1. There are many ways to improve SQL query performance.
The basic rules are to use simple types (primitives, String, UUID and some
other JDK classes),
use inices with proper inline size to avoid unnecessary row lookups, use
right collocation.
2. This will not work. Ignite fully relies on
The SQL queries are not getting me performance that I want. So I was trying
for alternative methods to handle the same using get.
Like getting the data using cache.get() and filtering them with the sql
operations that I actually wanted to do.
Suppose I have an equals method which will have two
Ignite stores data in binary form and has its own algorithms for
hashCode/equals that are based on binary representation to avoid
deserialization. Therefore overriding equals would not have any affect.
Actually, I'm not sure I understand why you want to override it in the first
place. The
