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 BERT as the serialization format, making implementing JavaScript M/R functions a little easier, and interop with other languages. Sean Cribbs <s...@basho.com> Developer Advocate Basho Technologies, Inc. http://basho.com/ On Jun 9, 2011, at 5:14 PM, Andrew Berman wrote: > 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 itself > (Erlang binary) and then just converting the binary back to the record when I > pull them from Riak. I was wondering what the pros/cons are to this > approach. Here's my list so far: > > Pros: > > Native Erlang is stored, so less time to convert to the record > Better support for nested records > Smaller storage requirements and hence faster on the wire (?) > > Cons: > > Not readable through Rekon (or other utils) without modification > Can't use standard M/R functions which analyze the document (have to write > all custom functions using Erlang) > Not portable across languages > > Thanks, > > Andrew > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
