incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Blur capability question
Date Tue, 02 Dec 2014 12:38:13 GMT
On Mon, Dec 1, 2014 at 8:23 PM, Mark Kerzner <mark@elephantscale.com> wrote:
> Aaron,
>
> I am really grateful for such a complete answer. As an aside, is there a
> book or a document where this kind of reference is collected? Surely I will
> have my own notes.

These explanations are [mostly] covered throughout the API
documentation[1] but unfortunately, no, it's not nicely collected in
one spot - I've just added a ticket for that[2].

> For my future purpose - to give the user the latest updates that have made
> it into the index yet - it seems that way 2. is the closest.

To give the user the most recent data 1 is the way to go.  The
tradeoff being that the thrift mutate calls provide instant access at
the tradeoff of [relatively] lower overall indexing throughput.  2 is
slightly slower [but configurable as Aaron mentioned] access to new
data, but has the advantage of a higher throughput.

> Do I
> understand correctly that Blur will keep indexing for 5 seconds
> (configurable), while the user, who searches against the index, will not
> see the new results?

Yes, that's correct.

> However, there is a queue in front of the index that
> one can query separately?

The queued docs are currently not accessible at all.  In any of these
indexing  approaches, Blur [currently] doesn't support uncommitted
results to be returned. Probably most of us just haven't come across a
scenario where that behavior would be considered a "Good Thing" :)


Thanks,
--tim

Mime
View raw message