riak-users Digest, Vol 33, Issue 29
rzezeski at basho.com
Mon Apr 23 19:26:34 EDT 2012
Elias, comments inline.
On Fri, Apr 20, 2012 at 12:15 PM, Elias Levy <fearsome.lucidity at gmail.com>wrote:
> I disagree. Yes, Riak is in general a simple system from an architecture
> standpoint. But often the that simplicity is an obstacle, as you must
> solve more complex problem using Riak as a base.
I agree, distributed systems are hard, even when they are simple.
> How to trade off between secondary indexes and search?
This is an area I am actively working on, it just isn't too visible to the
outside world yet. I've recently started a prototype to fuse the 2i
interface on top of Search's engine.
> How to configure search indexes so it does not blow up when you got very
> high volume low cardinality or very high cardinality terms (faking
> multicolumn indexes and bucketing)?
I'm also doing work on this to make conjunction queries safer, do less
work, and have better latencies. A query that produces a "large" result
set is still problematic but a conjunction of small and large result sets
will be much, much better. I saw very significant improvement on a
particular work load but I need to do more benchmarking on "real" hardware.
> How to reindex data in the store?
> How to repair data in the store if you loose a node without the Enterprise
These are two HUGE pain points in Search. Currently it is my #1 problem to
address and it will be a multi-faceted approach. The first thing I'm doing
is building a repair cmd which will allow you to specify a broken partition
and it will smartly rebuild it based on the surrounding partitions. I've
already done a prototype that passes some basic tests but it has diverged
into some riak_core work to help support it. These are the prototype
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users