riak on one node

Curtis Schofield curtis at ram9.cc
Mon Oct 1 20:42:46 EDT 2012

Thank you Dmitry.

It is my instinct now that i have done this is that I am using Riak for a
wrong application of it - Actually after some thought and writing - I
believe that what i really need is a slow log and that can be created after
the fact and that I should continue to focus on using the local file system
and memory.

And I also came to the conclusion that a slow log implemented with
postgresql would be appropriate and have the durability i wish.

Thank you for your insights and response - I will use a pastebin / gist in
the future.

On Mon, Oct 1, 2012 at 5:36 PM, Dmitry Demeshchuk <demeshchuk at gmail.com>wrote:

> 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

Modern Yoga vs Traditional Yoga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20121001/542144a0/attachment.html>

More information about the riak-users mailing list