Web doc buglet
guido.medina at temetra.com
Wed Oct 31 13:28:04 EDT 2012
HA proxy + Riak + ElasticSearch are your friends, Solr lacks
documentation (way outdated), hard to find stuff done and samples, so if
you have your cluster well setup and your meaning to do only key-value
retrieval with assist of text index search using ElasticSearch, you are
*Note:* We have Solr for GeoSpatial functionality and is amazingly fast,
but there isn't much we can do, if you need complex polygon features it
gets complicated in Solr. Except for some incubation projects that will
be brought into Solr, it is kind of hard to do anything.
Hope that helps,
On 31/10/12 17:15, Mark Phillips wrote:
> Hi Tin,
> On Mon, Oct 29, 2012 at 2:23 PM, Tin Le <tin at le.org> wrote:
>> Hi Mark,
>> Thanks. I've opened new issue for this outdated fast-track doc. I am
>> sure I'll be adding more as I or my engineers find them.
> Thanks for the report. I'll take a stab at getting that added/modified
> by the end of the week.
>> One of the thing we've found missing and really need is the geospatial
>> indexing mongodb has. We've just pushed our updated app to both iTunes
>> and Google Playstore that uses this as an intrinsic part of our app. We
>> decided to stay with mongo as there was no time to code up equivalent for
> So Riak isn't really a great fit for geospatial right now. You might
> be able to fake it to some extent using secondary indexes and doing
> range queries on lat/longs (stored as ints) but it might not be too
> performant. The other thing worth noting is that Ryan Zezeski has been
> hacking on a revised implementation of Riak Search that ties Riak and
> Solr together quite nicely (and thus supports geospatial). It's called
> Yokozuna , and it's still alpha, but it's worth looking at and
> testing (as this code getting more stable pretty quickly).
> What are the specifics of the use case?
>> The docs for riak isn't too bad. It seem to be lagging behind in
>> documenting the new features. I've also seen conflicting
>> recommendations. There was recent discussion about 256, 512 or even
>> higher number of partitions in production deployment. I know I saw that
>> in one of the fast start doc. There was no explanation in the doc as to
>> why chose a particular number for a usage pattern.
> Most people will run with either 64, 128, 256, 512, or in some case
> 1024. 64 ,128, 256 and 512 are probably the most frequently used, and
> are optimal for physical node counts of up to ~10, ~20, ~40, and ~90,
> respectively. Keep in mind that when I say "optimal" I mean "is taking
> advantage of Riak's vnode architecture for performance." Running 20
> nodes on a cluster with 64 partitions, while not "optimal", will work
> fine. That said, we're working on making ring sizing easier and more
> flexible. There won't be any major work on it for a few releases at
> the earliest, but we're well aware that it needs to be simplified.
> Your hardware will dictate the ring size in a lot of case. Any idea
> what you'll be working with?
>> So things like that is frustrating for me and my engineeres, who has
>> never used riak before. I would like to see a single Best Practices doc
>> for sysadmin/operations who has to set up a cluster and manages it. Then
>> another for the developers who will be using riak.
> We have a fairly extensive "Operations" section on the wiki, but I'm
> sure we're missing some things your team needs. Anything specific that
> comes to mind based on what's in the Ops section?
>> The fast-track doc is good, but it need to be maintained and keep
> Agreed. We're working on it.
>> Sorry, just a quick dump of stuffs from my head.
> No reason to apologize. You're only making Riak better. :)
>  github.com/rzezeski/yokozuna
>>> Hi Tin,
>>> Responses in-line.
>>> On Mon, Oct 29, 2012 at 1:18 PM, Tin Le <tin at le.org> wrote:
>>>> Sorry if this is the wrong place. Is there a specific email address I
>>>> can send to for buglets I found on Basho doc site?
>>>> Does not mention "GET /buckets/bucket_name" that this page does:
>>> If you have any docs bugs that need filing, go ahead and add them here:
>>> We usually get to them pretty quick. (Bonus points for submitting pull
>>>> I am trying to convince our engineers to move from mongo to riak, and
>>>> running various doc snafus.
>>> As far as convincing your team to move to Riak, what are the specific
>>> doc (and general) snafus that are standing in your way right now?
>>> We'll get them straightened out. :)
> riak-users mailing list
> riak-users at lists.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users