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 <voze...@gridgain.com> wrote: > 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 <dsetrak...@apache.org> > wrote: > >> On Wed, Oct 25, 2017 at 3:32 AM, Vladimir Ozerov <voze...@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? >> > >
