On 07 Mar 2014, at 16:21, Sanne Grinovero <sanne(a)infinispan.org> wrote:
> Is it possible to use an index for x-cache joins with linear index update time and
query?
Index update cost is not linear but LogN: approximates to a constant
cost. And we could cut this constant by 4 orders of magnitude if only
I could safely differentiate between a put of a new entry vs. an
update -> something which we'll need to brainstorm about.
Query time is also significantly sub-linear in practice, but specifics
will vary on the query type.
Yes you could use indexes to improve x-cache joins, but you'll need an
additional engine to coordinate that correctly, not least to manage
data size buffers; essentially I think you'd need Teiid.
I think Mircea means implementing joins across different caches if the foreign key is
indexed.
It would basically require N index seek (N being the number of fk value on your left hand
side) per join and some aggregation engine to link the elements matching from the two
side.
So N^M
M= # of joins
N= # of distinct FK involved
Does that reasoning sound right?