On Sat, Jan 7, 2012 at 5:00 PM, Ryan Zezeski wrote:
> I hope this makes some sense. I realize I've completely ignored your
> range vs. prefix query question but that's because I don't think that's the
> real issue here.
>
Actually meant to reply earlier, but got side tracked. I'll look deeper
Elias,
I'm assuming you have one composite field that looks like so:
__
where is ISO8601 basic format down to an hour resolution.
If this is the case then you _cannot_ perform an efficient, nor correct
(without doing extra work in your application), query on the portion
of the field. To use
I was wondering whether some of the Basho folk may have some wise words
about when to choose between ranges and wildcards when using Riak Search.
I've noticed in our systems that using wildcards will often give more
performant results than using ranges, at least for our data and some of the
indexe
will yield many results. My understanding of the
>> implementation of Riak [citation needed] is that the search is divided into
>> a few phases. The first one is collecting results for each term. After that
>> comes merging, sorting and limiting the result set. So for this particular
FYI I got this reaction from Elias (this is a forward it to the list so it
will be archived correctly. Thank you Elias btw)
On Wed, Nov 30, 2011 at 5:45 PM, Elias Levy wrote:
> On Wed, Nov 30, 2011 at 6:01 AM, wrote:
>
>> From: Jeroen van Dijk
>>
>> The use case I'm talking about is when you are
limit is set because limiting comes in a phase after collecting
> and the merging of results.
>
> The first question is, can the above be confirmed? I've read about Riak
> Search performance optimization here [3], but that seems to be for a
> different problem.
>
> I'
mes in a phase after collecting
and the merging of results.
The first question is, can the above be confirmed? I've read about Riak
Search performance optimization here [3], but that seems to be for a
different problem.
I've read here [1] that one can use search_fold to interrupt the collec
t;>
>> Since Riak Search has been in use for some time with beta testers, I'm
>> wondering if Basho might share some performance insights, especially if its
>> possible to compare customers who were using Solr and have switched to Riak
>> Search, which would be o
On 10/18/2010 1:36 PM, Rusty Klophaus wrote:
Hi Neville,
Thanks! Performance comparisons are tricky business. Any time you
compare a distributed system to a non-distributed system on a single
machine, the non-distributed system is going to be much, much faster
simply because it can skip all of t
e performance insights, especially if its
> possible to compare customers who were using Solr and have switched to Riak
> Search, which would be our use case.
>
> For example, would Riak Search performance be comparable to Solr over say
> 1M 1K docs, assuming sufficient RAM and fast
Hi Guys,
Its a great work to make search with erlang-lucene family.
I wonder is there any benchmarks withs 10M+ web documents ?
We have subseconds performance with 12M docs on SOLR. But maintaining keeping
the system alive
sometimes a nightmare...
Can we solve our problems with riak_search ?
omers who were using Solr and have switched to Riak
Search, which would be our use case.
For example, would Riak Search performance be comparable to Solr over say
1M 1K docs, assuming sufficient RAM and fast disk ?
Thanks for any performance insights from your beta testing experiences
Kind Re
12 matches
Mail list logo
