riak on one node

Dmitry Demeshchuk demeshchuk at gmail.com
Mon Oct 1 20:36:10 EDT 2012


Judging by the wiki,

Changing the N value after a bucket has data in it is not recommended. If
you do change the value, especially increasing it, you might need to force
read repair. Overwritten objects and newly stored objects will
automatically be replicated to the correct number of nodes.

Another possible thing is that you've been expecting an answer from 2 or
more nodes, while n_val for the bucket was already set to 1. Can you show
your client code?

But, before you do that, let me mutter a bit:

1. Storing cached data at disk? Okay, if you really want to do it, use
Bitcask, not LevelDB. Bitcask has expiration time for keys, and it *might*
save you from running out of disk space, unlike LevelDB. But using disk,
even the fastest SSDs for caching is mostly a bad idea in advance, no
matter how fast your caching database is.


2. One-node Riak isn't a good thing either. Riak literally shines when you
have a lot of nodes. The more – the better (well, I wouldn't build a
cluster of more than 200-300 nodes, due to Erlang "each-to-each" node
communication behavior). But large scale clusters, like 10+ – that's where
it shows the most strong qualities, that the other databases mostly lack.
We are running Riak in production and are glad of it. But we realised that
even running 3-4 nodes is generally pointless: you can hardly benefit from
this approach.

In case of one node, I'll tell you what I generally tell people when they
ask abstract "Should I use Riak?" questions: if you are not sure what you
are doing – use something like Postgres. I'm not convincing you to stop
using Riak or something – it just seems you are trying to use it for a
wrong purpose, and instead of being satisfied with a product you'll
probably end up strongly disappointed.


3. From what I remember, secondary indexes are very slow (guys from Basho,
I'd be glad to be wrong, since we are eager to use 2i at some places, so
please correct me if they've become significantly faster). So, not only you
are trying to use a database that is meant to be distributed (so, even on 1
node involves extra overhead that wouldn't exist in non-distributable DB),
not only you are using disks, that are far slower than memory, but you are
also using 2i, which would make Riak even slower for you.


TL;DR: You seem to be trying to use Riak for a very wrong purpose. Use
something that has been designed for caching stuff: memcached, CouchBase
(former Membase, don't mix it up with CouchDB) or Redis.


P.S. Seriously, people, use pastebin or GitHub gists to post large amounts
of config/code.


On Tue, Oct 2, 2012 at 4:06 AM, Curtis Schofield <curtis at ram9.cc> wrote:

>
> I do not believe that this is the best use of memcache - I have switched
>> to the filesystem for now - I could imagine this
>> system becoming very large and it would be useful to have a cluster
>> holding the server traffic.
>>
>>     I think i meant to say - this may not be the best use of riak - it
> may be better to use memcache.
>
>
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>


-- 
Best regards,
Dmitry Demeshchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20121002/970d435e/attachment.html>


More information about the riak-users mailing list