[ANN] The Future of Ripple

Bryce Kerley bryce at basho.com
Wed Oct 9 15:11:04 EDT 2013

tl;dr: Ripple has not been maintained because we've learned that it's not the right way to think about Riak. Using the riak-client APIs directly leads to better applications. We're moving Ripple to basho-labs to avoid confusion.

The Ripple State of Mind

The Ripple document-relational mapper tool for Riak allows you to treat Riak objects like Ruby objects, very similarly to how ActiveRecord lets you treat Postgres rows like Ruby objects. This neglects the fundamental differences between Postgres and Riak, and encourages developers to use Riak badly.

SQL is a nice fit for Rails-like object usage because adding indexes isn't prohibitively expensive, querying with indexes is cheap, and there's a query planner that can use or mix indexes when available, and can resort to a table scan when they're not. Ripple, while it does have secondary index (2i) support, doesn't have a planner to do set math on multiple indexes, so you either get to implement that yourself or write composite indexes. Adding an index after you have a dataset in production is hard too; it either only applies to new data or requires an expensive migration step, in which you load and re-save old records.

Missing Features

Ripple doesn't provide any way to use some Riak 1.4 and 2.0 features, such as streaming 2i, multi-get, 2i return terms, and CRDTs. Ripple also doesn't make it easy to make your front-end vector-clock aware, which limits its usefulness in scenarios that create siblings.

These are complex features, and trying to wrap them in Ripple won't necessarily make them easier to use.

My experience with complex Rails-style applications is that models eventually grow a bunch of class and instance methods to handle cases that are awkward for the ORM layer; an ActiveRecord model might have a SQL-using method as an optimization for a specific use case, or instance methods that perform a write and return something sensible in the case of a Postgres constraint violation.

Replacing Ripple

Rails applications that want to use SQL without using ActiveRecord's ORM can do so: just useconnection.select_all and write some SQL. With Ripple, you can always drop down to riak-ruby-clientand do work that way.

With that in mind, instead of the generic Riak 1.0 feature set in Ripple, we recommend wrapping Riak client methods in model objects; this exposes more complexity initially, but as your application grows and evolves, provides better opportunities to integrate new Riak features that help queryability, denormalization to reduce the number of Riak interactions that have to be done, automate certain data types, or provide consistency guarantees in appropriate situations.

Ripple Today

We're moving Ripple to the basho-labs organization on GitHub to accurately reflect its status as unmaintained and deprecated.

Bryce Kerley
Software Engineer
Basho Technologies
bryce at basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20131009/a70f5c4c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: not available
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20131009/a70f5c4c/attachment.p7s>

More information about the riak-users mailing list