On Mar 6, 2014, at 9:21 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
On Wed 2014-03-05 17:16, Mircea Markus wrote:
> Sanne came with a good follow up to this email, just some small clarifications:
>
> On Mar 4, 2014, at 6:02 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
>>>> If you have to do a map reduce for tasks so simple as age > 18, I
think you system better have to be prepared to run gazillions of M/R jobs.
>>>
>>> I want to run a simple M/R job in the evening to determine who turns 18
tomorrow, to congratulate them. Once a day, not gazzilions of times, and I don't need
to index the age filed just for that. Also when it comes to Map/Reduce, the drawback of
holding all the data in a single cache is two-folded:
>>> - performance: you iterate over the data that is not related to your query.
>>
>> If the data are never related (query wise), then we are in the database split
category. Which is fine. But if some of your queries are related, what do you do? Deny the
user the ability to do them?
>
> Here's where cross-site query would have been used. As Sanne suggested (next
post) these limitations overcome the advantages.
No. Cross-cache query if implemented will not support (efficiently
enough) that kind of query. Cf my wiki page.
yes, non-indexed joins would be exponential on the number of caches involved. Is it
possible to use an index for x-cache joins with linear index update time and query?
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)