ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: affinity key syntax
Date Wed, 25 Oct 2017 10:42:02 GMT
For example, currently every table in Ignite has at least two PK indexes -
one for cache operations, and another one for H2. If you have two tables
(parent - child), you have either 4 indexes (if they are in different
groups), or 3 indexes (same logical group). But even if certain tree is
shared between caches, dependent data entries are located in completely
different parts.

With Spanner we will need only 1 index for both tables.

On Wed, Oct 25, 2017 at 1:39 PM, Vladimir Ozerov <vozerov@gridgain.com>

> In Spanner once parent key is found you don't need to search for child
> keys from scratch - they are located just after the parent key in the tree.
> In Ignite child and parent keys are located in different trees, hence more
> lookups are needed.
> On Wed, Oct 25, 2017 at 1:36 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>> On Wed, Oct 25, 2017 at 3:32 AM, Vladimir Ozerov <vozerov@gridgain.com>
>> wrote:
>> > Dima,
>> >
>> > Yes, I saw it also. But this is not about syntax only. Spanner use this
>> > information to store data efficiently - child entries a located near to
>> > their parents. We can think of it as if all related tables were logical
>> > caches inside one physical cache, sorted by the key. With this storage
>> > format it will be possible to implement very efficient co-located joins.
>> >
>> Hm... I don't think Ignite's approach for collocated joins is lees
>> efficient. However, back to Spanner, the first value in the child table
>> key
>> is the parent table key. This tells me that Spanner collocates based on an
>> approach very similar to Ignite's affinity key. Am I wrong?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message