Question on Key choice for an Ignite cache

[Eugene McGowan <eu...@gmail.com>]

We would like to create an Ignite key by concatenating data. This is a
standard distributed system pattern for key-value, and would allow the
reader and writer consistently access the cache.  The data is a combination
of strings and integers. To simplify our use case, lets say its an email
address (foo@bar.com) and phone number (123444) we want to use to build our
key.Our key could therefore be:foo@bar.com_123444 <fo...@bar.com_123444>The
advantage of this approach is the key can easily be read/debugged. Is there
a more optimum format for Ignite though? For regular RDBMS, it seems
integers were the default choice. We could convert foo@bar.com to an int,
e.g. f converts to 6, o to 15, etc.
This naïve first attempt of conversion would of-course lead to clashes, as
111 could map to either aaa or ak. This could be worked around potentially,
so looking for an initial steer on what Ignite would prefer as a key (i.e.
strings or ints). Is hashing something that would be recommended either? In
terms of any partitioning type logic, we are guessing not, but just more
around creating deterministic, unique keys

Re: Question on Key choice for an Ignite cache

[Denis Magda <dm...@apache.org>]

He Eugene,

To elaborate on Ilya's answer, you can define a POJO for your key like as
follows:

public class AccountKey {
    String email;
    String phoneNumber;

    //don't forget to implement equals() and hashCode() so
    // that Ignite partitions and locates your records properly
}

and then use the objects of that type in your cache.get/put requests.

-
Denis


On Tue, Jun 30, 2020 at 1:04 PM Eugene McGowan <eu...@gmail.com>
wrote:

>
> On Tue 30 Jun 2020, 13:51 Ilya Kasnacheev, <il...@gmail.com>
> wrote:
>
>> Hello!
>>
>> You can also use Binary Object (POJO) as a key, i.e., you can use an
>> Object with String email and String phone fields.
>>
>> I don't recommend mangling strings further than concatenation. String key
>> is no worse than numeric key.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 30 июн. 2020 г. в 15:17, Eugene McGowan <eu...@gmail.com>:
>>
>>>
>>> We would like to create an Ignite key by concatenating data. This is a
>>> standard distributed system pattern for key-value, and would allow the
>>> reader and writer consistently access the cache.  The data is a combination
>>> of strings and integers. To simplify our use case, lets say its an email
>>> address (foo@bar.com) and phone number (123444) we want to use to build
>>> our key.Our key could therefore be:foo@bar.com_123444
>>> <fo...@bar.com_123444>The advantage of this approach is the key can
>>> easily be read/debugged. Is there a more optimum format for Ignite though?
>>> For regular RDBMS, it seems integers were the default choice. We could
>>> convert foo@bar.com to an int, e.g. f converts to 6, o to 15, etc.
>>> This naïve first attempt of conversion would of-course lead to clashes,
>>> as 111 could map to either aaa or ak. This could be worked around
>>> potentially, so looking for an initial steer on what Ignite would prefer as
>>> a key (i.e. strings or ints). Is hashing something that would be
>>> recommended either? In terms of any partitioning type logic, we are
>>> guessing not, but just more around creating deterministic, unique keys
>>>
>>

Re: Question on Key choice for an Ignite cache

[Eugene McGowan <eu...@gmail.com>]

On Tue 30 Jun 2020, 13:51 Ilya Kasnacheev, <il...@gmail.com>
wrote:

> Hello!
>
> You can also use Binary Object (POJO) as a key, i.e., you can use an
> Object with String email and String phone fields.
>
> I don't recommend mangling strings further than concatenation. String key
> is no worse than numeric key.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 30 июн. 2020 г. в 15:17, Eugene McGowan <eu...@gmail.com>:
>
>>
>> We would like to create an Ignite key by concatenating data. This is a
>> standard distributed system pattern for key-value, and would allow the
>> reader and writer consistently access the cache.  The data is a combination
>> of strings and integers. To simplify our use case, lets say its an email
>> address (foo@bar.com) and phone number (123444) we want to use to build
>> our key.Our key could therefore be:foo@bar.com_123444
>> <fo...@bar.com_123444>The advantage of this approach is the key can easily
>> be read/debugged. Is there a more optimum format for Ignite though? For
>> regular RDBMS, it seems integers were the default choice. We could convert
>> foo@bar.com to an int, e.g. f converts to 6, o to 15, etc.
>> This naïve first attempt of conversion would of-course lead to clashes,
>> as 111 could map to either aaa or ak. This could be worked around
>> potentially, so looking for an initial steer on what Ignite would prefer as
>> a key (i.e. strings or ints). Is hashing something that would be
>> recommended either? In terms of any partitioning type logic, we are
>> guessing not, but just more around creating deterministic, unique keys
>>
>

Re: Question on Key choice for an Ignite cache

[Ilya Kasnacheev <il...@gmail.com>]

Hello!

You can also use Binary Object (POJO) as a key, i.e., you can use an Object
with String email and String phone fields.

I don't recommend mangling strings further than concatenation. String key
is no worse than numeric key.

Regards,
-- 
Ilya Kasnacheev


вт, 30 июн. 2020 г. в 15:17, Eugene McGowan <eu...@gmail.com>:

>
> We would like to create an Ignite key by concatenating data. This is a
> standard distributed system pattern for key-value, and would allow the
> reader and writer consistently access the cache.  The data is a combination
> of strings and integers. To simplify our use case, lets say its an email
> address (foo@bar.com) and phone number (123444) we want to use to build
> our key.Our key could therefore be:foo@bar.com_123444 <fo...@bar.com_123444>The
> advantage of this approach is the key can easily be read/debugged. Is there
> a more optimum format for Ignite though? For regular RDBMS, it seems
> integers were the default choice. We could convert foo@bar.com to an int,
> e.g. f converts to 6, o to 15, etc.
> This naïve first attempt of conversion would of-course lead to clashes, as
> 111 could map to either aaa or ak. This could be worked around potentially,
> so looking for an initial steer on what Ignite would prefer as a key (i.e.
> strings or ints). Is hashing something that would be recommended either? In
> terms of any partitioning type logic, we are guessing not, but just more
> around creating deterministic, unique keys
>