How would we tell the m/r that the data type is BSON? Does the js engine already have BSON support included?
- Jon Langevin -- sent from my Android phone On Jun 14, 2011 12:47 PM, "Will Moss" <wm...@bu.mp> wrote: > 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
