Does equals method have relevance in Custom Key Class

[the_palakkaran <ji...@suntecsbs.com>]

Hi,

Does overriding equals method in my CustomKey class has any relevance in
cache.put and cache.get ? When I checked, they were not getting executed
while put and get.

Also I understand that ignite does not want us to override of equals method
in Binary Objects. Is there any way to override this? 

Suppose I have multiple CustomKeys that implement BinaryObject, then it
would have been benefical if I could just use theys keys to get results
diffrently.

For eg:  A custom key has an equals method that checks for a field to be
equal to 0 and for another key has an equals method that checks for a field
to be equal to 1.

When I tried, custom key to BinaryObjectEx casting exception was being
thrown.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Does equals method have relevance in Custom Key Class

[Andrey Mashenkov <an...@gmail.com>]

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 are unknown then the only way to retrieve entries
efficiently is to use some index: either SQL or implement your own custom
IndexingSPI,




On Wed, Jun 6, 2018 at 3:36 PM, the_palakkaran <ji...@suntecsbs.com> wrote:

> 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 ignite in the order high to low will be :
>
> 1. Using Binary Objects direct get
> 2. Using normal serialiazable objects
> 3. Using Externalizable direct get
> 4. Using SQLField query [ queries will always be the one taking most
> performance, from my experience]
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Does equals method have relevance in Custom Key Class

[the_palakkaran <ji...@suntecsbs.com>]

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 ignite in the order high to low will be :

1. Using Binary Objects direct get
2. Using normal serialiazable objects
3. Using Externalizable direct get
4. Using SQLField query [ queries will always be the one taking most
performance, from my experience]



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Does equals method have relevance in Custom Key Class

[Andrey Mashenkov <an...@gmail.com>]

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 deserialization of whole object, but this costs
some memory overhead.

2. See [2] for details. Inline size is a portion of key\column which will
be inlined into index tree.
So, when field value fit to inline size then Ignite will be able to
comparison instantly when scaning\updateing index.
Otherwise Ignite will go for data page (where entry actually resides) to
read field whole value for further comparison.

Proper inline size may significantly speed-up SQL index scans and updates
operations.


[1] https://apacheignite.readme.io/docs/binary-marshaller#basic-concepts
[2]
https://apacheignite-sql.readme.io/docs/create-index#section-index-inlining


On Wed, Jun 6, 2018 at 2:03 PM, the_palakkaran <ji...@suntecsbs.com> wrote:

> 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 right?
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Does equals method have relevance in Custom Key Class

[the_palakkaran <ji...@suntecsbs.com>]

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 right?





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Does equals method have relevance in Custom Key Class

[Andrey Mashenkov <an...@gmail.com>]

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 internal binary object
comparison methods rather than 'equals()' method.
Get operation is key-value API operation that expects key is unique for
each entry.
So, get() always return a single value.

Why you think your way is workable? Have you tried to validate it with JDK
HashMap?

On Tue, Jun 5, 2018 at 8:37 AM, the_palakkaran <ji...@suntecsbs.com> wrote:

> 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 return cases working
> based on a field value "Y" or "N". So there are basically two cases in
> equals which will get executed based on the field value. That way I can get
> results differently, right?
>
> for example in a customer key class, I have a customer id and a customer
> number fields. In my equals method I have something like this:
>
> if("Y".equals(field))
>         return (null != this.custNo && null != custNo &&
> this.custNo.compareTo(CustomerMaster.custNo) == 0)
> else
>         return (null != this.custId && null != custId &&
> this.custId.compareTo(CustomerMaster.custId) == 0)
>
> This would fetch me records differently, right?
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Does equals method have relevance in Custom Key Class

[the_palakkaran <ji...@suntecsbs.com>]

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 return cases working
based on a field value "Y" or "N". So there are basically two cases in
equals which will get executed based on the field value. That way I can get
results differently, right?

for example in a customer key class, I have a customer id and a customer
number fields. In my equals method I have something like this:

if("Y".equals(field))
	return (null != this.custNo && null != custNo &&
this.custNo.compareTo(CustomerMaster.custNo) == 0)
else
	return (null != this.custId && null != custId &&
this.custId.compareTo(CustomerMaster.custId) == 0)

This would fetch me records differently, right?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Does equals method have relevance in Custom Key Class

[vkulichenko <va...@gmail.com>]

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 following example is confusing:

> For eg:  A custom key has an equals method that checks for a field to be
> equal to 0 and for another key has an equals method that checks for a
> field
> to be equal to 1. 

You should compare two different objects for equality rather than comparing
different objects' fields with particular values. Can you clarify this?

-Val



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/