Based this latest description, simply not specifying an affinity key here
would be sufficient. But presumably you were specifying the affinity key
to cause co-location. The reason a lookup on the K of the KV pair is fast
is because it can hash to a node. If the affinity key was not included
My whole and sole requirement is to make lookup work fast, this can only be
achieved with lookup based on primary key, cluster knows which node is
holding this record based on the key, no other look-up can give best results
close to primary key lookup.
We have done some tests on lookup based on th
What is your goal? If you have a unique key that does not contain the
affinity key, and the primary key contains both fields, you can create an
index on that unique key, so that you could have fast node local lookups
using SqlQuery().If you want to find an object only by that original
unique
Because without AFFINITY KEY option we do not know order of fields within
composite PK which is very important for index creation.
вт, 20 марта 2018 г. в 19:58, Dmitriy Setrakyan :
> On Tue, Mar 20, 2018 at 2:09 PM, Vladimir Ozerov
> wrote:
>
>> Internally Ignite is key-value storage. It use key
On Tue, Mar 20, 2018 at 2:09 PM, Vladimir Ozerov
wrote:
> Internally Ignite is key-value storage. It use key to derive partition it
> belongs to. By default the whole key is used. Alternatively you can use
> @AffinityKey annotation in cache API or "affinityKey" option in CREATE
> TABLE to specify
Internally Ignite is key-value storage. It use key to derive partition it
belongs to. By default the whole key is used. Alternatively you can use
@AffinityKey annotation in cache API or "affinityKey" option in CREATE
TABLE to specify *part of the key* to be used for affinity calculation.
Affinity c
Yes, the affinity key must be part of the primary key. Welcome to my
world
On Fri, Mar 16, 2018 at 3:23 AM, Naveen wrote:
> Hi Mike
>
> I have created a table called CITY
>
> : jdbc:ignite:thin://127.0.0.1> CREATE TABLE City ( city_id LONG PRIMARY
> KEY, name VARCHAR) WITH "template=repl
Hi Mike
I have created a table called CITY
: jdbc:ignite:thin://127.0.0.1> CREATE TABLE City ( city_id LONG PRIMARY
KEY, name VARCHAR) WITH "template=replicated";
No rows affected (0.224 seconds)
Creating a table called Person with affinity key as city_id
0: jdbc:ignite:thin://127.0.0.1> CREA
Hi Naveen
>If I do not have the affinity key column as part of the primary key, it
does
>not allow me to create the table itself.
Could you please explain how it doesn't allow you create the table? is there
any exceptions/errors messages?
Thanks,
Mike.
--
Sent from: http://apache-ignite-u
Do we have any update on this clarification regarding the affinity
Thanks
Naveen
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi Stan
If I do not have the affinity key column as part of the primary key, it does
not allow me to create the table itself.
If I want to execute a join query on both the tables, I had to use affinity
key to collocate the data
select p.party_id, a.party_id, first_name, A.SERVICE_ID_LIST from
Generally, you should have an index for each combination of fields you use in
a query. Primary key gives you an implicit index, but you need to create the
rest yourself.
In your case, I'd suggest to have AccountID as a primary key (without
PartyID) and also create a compound index for the pair (Ac
12 matches
Mail list logo