I think you may understood wrong,
I have 2 riak nodes running on the following ports 10018 and 10028.
I am able to connect with any of the riak node through python
interpreter ( program is running running, able to store and retrieve data).
But the problem is that
some times getting Could
Hi,
I fell in love with riak and riak-cs, I have migrated all my stack on it
(originally from mongodb).
But I have one big issue. I have a lot of key to request simultaneously and
thanks for multi_get implementation (ruby) it's already optimised for the
client side (concurrent requests). But I
There is a section in
http://docs.basho.com/riak/1.4.0/cookbooks/Linux-Performance-Tuning/:
If using LevelDB as the storage backend (which maintains its own I/O thread
pool), the number of async threads in Riak's default pool can be decreased
in the /etc/riak/vm.args file:
+A 16
Can I please
Vincent,
We will consider this for a future release of Riak. In the meantime, have
you considered JRuby for your app? It has much better multi-threaded
behavior than MRI.
On Tue, Oct 29, 2013 at 5:24 AM, Vincent Chavelle
vincent.chave...@gmail.com wrote:
Hi,
I fell in love with riak and
Hi and thank you for the reply. My comment follow:
Your tests are not close to what you are going to have in production
My tests are exactly what we will have in production. 1 node or in best case 2
nodes.
We don't care about durability here. Our request per second will be extremely
low
Hi Georgi,
All Guido’s (below) advice is good. If you are just importing unique items, I
would set the bucket property to LWW=true for the import, it will be much
faster since Riak will not do N local reads for vclock data.
Cheers
Russell
On 29 Oct 2013, at 15:21, Guido Medina
Den 29-10-2013 16:32, Georgi Ivanov skrev:
Hi and thank you for the reply. My comment follow:
Your tests are not close to what you are going to have in production
My tests are exactly what we will have in production. 1 node or in best case 2
nodes.
We don't care about durability here.
If you
On Tuesday 29 October 2013 16:50:25 Rune Skou Larsen wrote:
Den 29-10-2013 16:32, Georgi Ivanov skrev:
Hi and thank you for the reply. My comment follow:
Your tests are not close to what you are going to have in production
My tests are exactly what we will have in production. 1 node or
Hi,
I am looking around for different solutions for a good file-store and
the posibility to use Riak for that purpose.
As far as I understand, if I have a 10 node cluster with 2 replicas,
an object will be stored on a total of 3 nodes.
If I query a node where the object is NOT stored, the node
Hi.
we are load testing Riak 1.4.2 in the amazon cloud (8 nodes: c1.xlarge + 1
ebs) at the moment and plan to go into production early next year.
So far things have been going pretty well and we increased the load and the
total time of the load tests almost weekly.
The current target is a 24
Hey Riak-Users (and Riak-Core)
Some time ago, Basho released riak_core as a framework for building distributed
applications [1].
One of the key pieces of guidance that was given at the time was that you
should use the features
of riak_kv if your app needed to do any persistence. With the new
I have built a production like prototype using riak-core. My major issue was
luck of documentation (out-dated or missing aspects). So I spent about 5-7 days
in reading source code and writing tests. I think a simple sequence digram of
hinted hand-off would answer on many my questions. Please
If the requests from the clients are not so frequent, there might be
another option, to emulate multiget by running mapreduce with keylist
input. This will make Riak run cover operation internally, so the
throughput won't improve but latency would improve, because it runs
inside the server in
13 matches
Mail list logo
