Just a heads up if you are looking to dive right in: The client libraries still lag behind Riak itself, so it might be a while before you get all the goodness unless you plan to roll your own.
Yup. For haskell users, I have a trivial fork of Mailrank's riak-haskell-client that is tested to work with riak-1.0rc1; I haven't tried the secondary indices stuff yet, but it's possible that it would work too. It's at https://github.com/tsuraan/riak-haskell-client for anybody who wants to try it out.
I checked the protobuf spec, though, and Riak 1.0 is completely compatible with the older client libraries. All the changes are backward compatible. So you get perhaps 90% of the new hotness.
There will be a minor gem release (pre/beta/something) next week that supports Riak 1.0 features, then in the next major release those will also bubble up to the Ripple document layer. Sorry for the delay.
Most of the HTTP and PBC apis are the same so everything that has already been implemented should still work. I know they haven't added official support for secondary indexes, but I hacked them together real quick here: https://github.com/highgroove/ripple
I think I heard next week sometime the 1.0 ready ripple will be out. As others have said all clients will work with riak 1.0, they just might not support all of the new hotness.
Congratulations! I hope no Basho employees were injured in the last couple days of what, reading between the lines, sounded like a hard fought battle!
I'm about to dig in and read the release notes, upgrade etc, but I've been keeping up with the betas, so here's my early thoughts on Riak 1.0.
With 1.0 Basho has really started to separate from the pack.
I think secondary indexes are very well implemented and while they can be expanded feature wise over the years, as an %80 solution they are a no brainer-- and pack the double whammy of cutting developer time, and by efficiently reducing scope of Map/Request processing they can also boost performance.
I think the real sleeper hit, though, is riak_pipe. This moves Riak from just being a "database" or even a "batch processing system" into a realtime platform. I think in 3 years, this will be seen as the feature that put the elbow in Riak's growth. I'm hoping to have high level support for riak pipe in Nirvana when its released, and can't wait to start using it. Once again, I think you've saved me a couple months of work.
I know a lot of work was done on supporting new backends, specifically, LevelDB, and consolidating/unifying the existing ones (like merging ETS and Cache into the new RAM backend.) I think a blog post on each of the backends and when best to use them would be very useful (though this might be covered in the new docs.)
And Search Integration. I think this is the first NoSQL solution with built in, scalable, full text search.
Before, if you'd decided to go NoSQL, you kinda had to decide which architecture worked best for you and hope they had the features you wanted. I chose Riak because, I believe, it has the best architecture for the class of problems I'm solving... but now it also has a very complete set of features. I'm not sure if any of the competition is as complete out of the box, but even if they are, Riak should be in a lot more evaluations than it has been in the past.
Further, everything is so elegantly engineered that you've built an exceedingly attractive platform for us developers.
riak_pipe... moves Riak from just being a "database" or even a "batch processing system" into a realtime platform
Interesting - could you explain more about this? I've not really grokked Riak's map-reduce yet, and all I understood from the blog post about riak_pipe was that it was a new layer under the hood but didn't change the programming model for map-reduce queries. Is it simply that it's so much faster as to permit new use cases?
This sounds too flattering toward Riak; it almost sounds like an ad rather than an external congratulation. But what are the downsides & disadvantages of Riak when compared with other contenders? Why do you like it so much more?
[+] [-] dsl|14 years ago|reply
[+] [-] tsuraan|14 years ago|reply
[+] [-] pjscott|14 years ago|reply
[+] [-] nosequel|14 years ago|reply
[+] [-] rb2k_|14 years ago|reply
[+] [-] seancribbs|14 years ago|reply
[+] [-] vanstee|14 years ago|reply
[+] [-] nosequel|14 years ago|reply
[+] [-] nirvana|14 years ago|reply
I'm about to dig in and read the release notes, upgrade etc, but I've been keeping up with the betas, so here's my early thoughts on Riak 1.0.
With 1.0 Basho has really started to separate from the pack.
I think secondary indexes are very well implemented and while they can be expanded feature wise over the years, as an %80 solution they are a no brainer-- and pack the double whammy of cutting developer time, and by efficiently reducing scope of Map/Request processing they can also boost performance.
I think the real sleeper hit, though, is riak_pipe. This moves Riak from just being a "database" or even a "batch processing system" into a realtime platform. I think in 3 years, this will be seen as the feature that put the elbow in Riak's growth. I'm hoping to have high level support for riak pipe in Nirvana when its released, and can't wait to start using it. Once again, I think you've saved me a couple months of work.
I know a lot of work was done on supporting new backends, specifically, LevelDB, and consolidating/unifying the existing ones (like merging ETS and Cache into the new RAM backend.) I think a blog post on each of the backends and when best to use them would be very useful (though this might be covered in the new docs.)
And Search Integration. I think this is the first NoSQL solution with built in, scalable, full text search.
Before, if you'd decided to go NoSQL, you kinda had to decide which architecture worked best for you and hope they had the features you wanted. I chose Riak because, I believe, it has the best architecture for the class of problems I'm solving... but now it also has a very complete set of features. I'm not sure if any of the competition is as complete out of the box, but even if they are, Riak should be in a lot more evaluations than it has been in the past.
Further, everything is so elegantly engineered that you've built an exceedingly attractive platform for us developers.
Bravo, and thank you very much!
[+] [-] samstokes|14 years ago|reply
Interesting - could you explain more about this? I've not really grokked Riak's map-reduce yet, and all I understood from the blog post about riak_pipe was that it was a new layer under the hood but didn't change the programming model for map-reduce queries. Is it simply that it's so much faster as to permit new use cases?
[+] [-] oconnor0|14 years ago|reply