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 <cur...@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@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- Best regards, Dmitry Demeshchuk
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
