Would the Riak standard map/reduce be able to deal with BSON properly, or would map/reduce functionality be less efficient than if it were inspecting JSON objects?
<http://www.loomlearning.com/> *Jonathan Langevin Systems Administrator Loom Inc. Wilmington, NC: (910) 241-0433 - jlange...@loomlearning.com - www.loomlearning.com - Skype: intel352* On Thu, Jun 9, 2011 at 5:26 PM, Will Moss <wm...@bu.mp> wrote: > 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 haven't tried using it in a Erlang map-reduce yet (we don't do > map-reduces for any of our production work), but there is a library out > there so it shouldn't be too hard. > > Will > > > On Thu, Jun 9, 2011 at 2:24 PM, Sean Cribbs <s...@basho.com> wrote: > >> 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 >> > > > _______________________________________________ > 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
