I still haven't had a chance to try out using BSON for a map-reduce, but in general, parsing BSON is faster than parsing JSON and I'd imagine that's true in Erlang as well. So, I'd assume using BSON is faster, but you know what they say about assumptions...
Will On Tue, Jun 14, 2011 at 9:40 AM, Jonathan Langevin < jlange...@loomlearning.com> wrote: > 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
