Hi Steve,
Riak does best with a lot of memory and a fast disk. Depending on how much
data you have in the system, putting two nodes into 1GB of memory on a
single VM may be causing the system to overrun available resources and page
out to disk, and depending on how you've set up your virtualized
e
What do you guys hate about Riak right now?
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
You can, I've done this, you have to modify the /etc/riak/vm.args to
include and start your application (assuming your application has a start/0)
function.
So if you have a foo app, you can add something like
-pa /usr/lib/erlang/lib/foo-0.0.0/ebin
-s foo_app
Then if foo_app.erl has something lik
While I am not a Developer Advocate, I hate that I cannot play Angry Birds
using the Basho logo.
On Jun 9, 2011, at 10:25 AM, Srdjan Pejic wrote:
> What do you guys hate about Riak right now?
> ___
> riak-users mailing list
> riak-users@lists.basho.co
+1
hornbeck
VP Client Services
Basho Technologies
On Jun 9, 2011, at 13:52, Scott Gonyea wrote:
> While I am not a Developer Advocate, I hate that I cannot play Angry Birds
> using the Basho logo.
>
> On Jun 9, 2011, at 10:25 AM, Srdjan Pejic wrote:
>
>> What do you guys hate about Riak r
I am using Riak using the Erlang Client API (PB) and I was storing my
documents as JSON and then converting them to records when I pull them out
of Riak, but I got to thinking that maybe this isn't the greatest approach.
I'm thinking that maybe it's better to store documents just as the record
itse
Andrew,
I think you're on the right track here, but I might add that you'll want to
have upgrade paths available if you're using records -- that is, version them
-- so that you can evolve their structure over time. That could be a little
hairy unless done carefully.
That said, you could use B
Hey Andrew,
We're using BSON (bsonspec.org), because it stores binary (and other) data
types better than JSON and is also faster and more wire efficient (sounds
like about the same reasons you're considering leaving JSON). There are also
libraries to parse BSON it in just about every language.
I
Hey Anthony,
Great question. We do have "Code Submission and Integration"
guidelines written up on the wiki:
http://wiki.basho.com/Code-Submission-and-Integration.html
(They were, admittedly, a touch out of date, so I just updated them to
reflect the current process.)
More specifically, a pull
I've followed the directions verbatim for setting up basho bench. I
successfully ran a test, but now I get the following error when running "make
results"
root@basho-bench:~/basho_bench# make results
priv/summary.r -i tests/current
/usr/bin/env: Rscript --vanilla: No such file or directory
make:
Hi,
Why not convert your term to a string, and then you can do map reduce can't you?
Term to a string...
1> Term = [{one,1},{two,2},{three,3}].
[{one,1},{two,2},{three,3}]
2> String = lists:flatten(io_lib:format("~p.", [Term])).
"[{one,1},{two,2},{three,3}]."
Save "String" in riak...
Then back
Ah, yes, you're right. Basically I'd have to either update all previous
record docs with the new field or I'd have to have multiple record
implementations to support the history of that particular record. That
could be really, really ugly.
Thanks Sean!
On Thu, Jun 9, 2011 at 2:24 PM, Sean Cribb
Cool, I've looked at BSON before for another project, and it might make
sense in this case as well.
Thanks!
On Thu, Jun 9, 2011 at 2:26 PM, Will Moss wrote:
> Hey Andrew,
>
> We're using BSON (bsonspec.org), because it stores binary (and other) data
> types better than JSON and is also faster a
Well, I'd rather not do it that way and converting it to a string. But
another thing I can do is convert the record to a proplist and then store
that in the database. When I pull it out of the database, I would have to
loop through the fields of the record definition, use each field as a key in
t
Firstly, thanks for the feedback. This is exactly what we were looking for!
It's pretty clear that people would find value in consuming the Recaps via
both email and blog/rss. So, that's what we are going to do :) Once the
initial setup is taken care of, posting a blog entry with the same content
I am not a developer advocate. But my top hate is that when machines
leave/rejoin your data can be inaccessable for some time.
We had a great case where we wanted to use Riak, but that was a
complete showstopper and we won't be using it because of that. (We
wanted to store information which need
This calls for silly hats.
It's a re-cap, heh.
http://rookery9.aviary.com.s3.amazonaws.com/8461000/8461482_11a7_625x625.jpg
If anyone likes silly hats I could certainly clean this up a lot.
On Thu, Jun 9, 2011 at 4:27 PM, Mark Phillips wrote:
> Firstly, thanks for the feedback. This is exac
Ben,
I hate non-obvious behavior too, and it's something we constantly try to
fight at Basho. That said, I don't think Riak is in as bad a position as
you think. Lets see if I can convince you :)
If I'm understanding you correctly you are making two points here:
1) When performing a join/leave
It sounds like you understood perfectly.
Basically we are running a cluster of machines that are busy doing
lots of stuff. We wanted to use Riak to keep configuration
information about those machines and the stuff they were doing. So
Riak would be running on machines whose primary job is somethi
On Thu, Jun 09, 2011 at 08:01:24PM -0700, Ben Tilly wrote:
> It sounds like you understood perfectly.
>
> Basically we are running a cluster of machines that are busy doing
> lots of stuff. We wanted to use Riak to keep configuration
> information about those machines and the stuff they were doin
Hello,
I have been debugging something I've seen popping up intermittently when
running my application's functional tests against Riak (local 5 node devrel
cluster). The behavior is basically that sometimes an object which was PUT will
seemingly disappear. Any future GETs will 404. Even if wait
21 matches
Mail list logo
