[firefox]

Yes, they do have some strengths like predictable performance and easy administration but they still have to improve on things like: - weak data model - difficult query API - poor single node performance - small community/weak adoption

[Ixiaus]

If you want just a single node, use Couch or Mongo - Riak wasn't built to work reliably OR quickly on a single node; Riak gets all of its fault-tolerance, low-latency, and great performance from > 3 node clusters (preferably > 5).

Weak data model is by design. It's a Key/Value store - if you need something more complex then it isn't the right fit for you; Riak is not meant to replace relational databases.

Small community? Certainly not. Weak adoption? Definitely not. Adobe is using Riak, Braintree, and hundreds of other LARGE companies.

The query API is pretty easy to use from the clients in my experience. If you want REAL performance you can write Erlang map/reduce workers - which admittedly gets more complicated but you get far more performance out of that than doing it in JS (which is limited on ANY platform, no just Riak).

Your gripes really aren't legitimate, purely because you're not understanding the use-case for Riak.

We use riak for ONLY TWO pieces of data in our app (out of hundreds of pieces). Everything else is in a relational database. Riak is perfect for FAST GROWING data that maps to the Key/Value model very easily; I can't even begin to describe how perfect Riak is for that. Everything else fits into MySQL/PostgreSQL perfectly and without a hitch. Our fast growing data is handled purely by Riak and Map/Reduce using Erlang workers is FAST.

[stock_toaster]

  > - poor single node performance

I am in the process of evaluating riak for an project, and have run across this too. I am not sure if it is specific to the eleveldb backend (I just used the default values so far), or just a bad config on my part. Even when I relaxed consistency down to r=1,w=1 and used the protobuf interface, riak was still performing rather slowly (compared to some other things I am testing) in single node performance.

[Ixiaus]

SERIOUSLY! Riak is NOT MEANT for single-node clusters!!! It gets faster THE MORE NODES YOU ADD.

The minimum recommended number of nodes is 3; the "ideal" minimum number of nodes is 5.

[stock_toaster]

yes, with n_val=3 (default) 3 nodes is the minimum. I was merely testing (actually had 3 riak instances on a single box as a "cluster") but with r,w=1 and n_val=1 it was about the same (slow), which was disconcerting. cpu was very high in one instance (others were nearly idle, and IO was low. I did not try dw=0 though (if that would even work). Might be worth a try.

I am going to try bitcask too, to see if eleveldb was the culprit and could be tuned.

[Ixiaus]

Your test isn't valid if it was all on one box - the disk I/O is going to be really nasty with that. Your test would be better on three different machines.

[stock_toaster]

The disk io was pretty low. It is serial get/update/delete (as I mentioned earlier). I even tried moving the data dirs to ramdisk (was plenty of ram), but it didn't help much at all. i/o was certainly not the problem.

It very well could be a configuration issue. I am still trying a few things to see if I can get an improvement.

[pharkmillups]

If you haven't done so already, I would highly-recommend taking a look at Basho Bench, our open source benchmarking tool for Riak.

http://wiki.basho.com/Benchmarking.html https://github.com/basho/basho_bench

[Ixiaus]

Interesting. I can vouch for the speed of leveldb on a five node cluster - I'm using it in our startup on 5 dedicated machines with around 12GB of RAM, running on FreeBSD. Riak version is 1.1.4; Riak 1.2 is supposed to have a lot of leveldb refinements.

[drsintoma]

What did you find slow? writes? retrieving by key? map-reduce? From what I've heard erlang map-reduce is much performant than the javascript one.

[stock_toaster]

It was a sequence simple operations (simple as in no 2i or mapred) of read an existing key A, check if a nonexistent key exists B, write a previously nonexistent key C, delete an existing key D, overwrite an existing key A.

All performed in serial over protobuf (python riak lib).

[Ixiaus]

LevelDB is known to have heavily degrading performance when you ask for a key that doesn't exist.

[jusben1369]

And what about Braintree? Why do they suck? Pretty well thought of with some great referencable customers.

[firefox]

Because we were a startup using it for about one year and paying the minimum price (I believe around $50/mo) plus another $15 fee/mo, plus they kept 6% of our transactions for 6 months (which we haven't seen any of it yet). Thankfully Stripe came into play (just as easy to implement) with zero monthly fees, and not holding any of our money. At that point we contacted Braintree to cancel our account and just then they offered a lower monthly fee (I believe around $20) and when I said no, they offered to match Stripe at zero cost. Why wouldn't they have offered this from the get go is beyond me and bad practice.

[klynch]

Kristi from Braintree here.

First, I want to apologize that we weren't able to reach out about lower fees sooner than we did. High fixed monthly fees have been imposed by the underlying banks that provide merchant accounts for years. Some banks have recently relaxed those and Braintree, Stripe and others in the industry are now able to take advantage of it.

The reason we were able to waive the fixed fee when you contacted us was not because it was in our discretion the entire time, but because we had only recently been able to get some of those fixed fees removed by the underlying banks. Since that time, we have been proactively contacting hundreds of our customers that would benefit from the new bank structure to offer them lower pricing.

The 6% reserve on your transactions wasn't imposed by Braintree but rather the bank that was providing your merchant account (Braintree is not holding back anyone's money). We work extremely hard to prevent reserves being imposed on our merchants and when it does happen, our intent is to get it removed as soon as possible. Please reach out to us so that we can work on getting your funds released asap.

We could have handled your situation better, and we're sorry that we weren't able to get lower fees to you faster. We've been browbeating banks for years on behalf of startups to get simpler, better fee structures. We've made a lot of progress and think we've had an impact on the industry with things like simpler pricing and card data portability. That said, we recognize there is a lot more work to do, and we will continue to work hard to provide an exceptional payments experience for startups.

[jusben1369]

Ok that's a valid negative experience.