couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Friesen <li...@danielfriesen.name>
Subject Re: Erlang vs Scala
Date Tue, 14 Apr 2009 18:36:41 GMT
Wout Mertens wrote:
> Hi Daniel,
>
> On Apr 13, 2009, at 7:01 AM, Daniel Friesen wrote:
>
>> In CouchDB we would have needed a structure similar to:
>> document aaa: { "isa": "jit", "state": {}, "children": ["bbb", "ccc"] }
>> document bbb: { "isa": "jit", "state": {}, "children": ["ddd"] }
>> document ccc: { "isa": "jit", "state": {}, "children": ["ddd"] }
>> document ddd: { "isa": "jit", "state": {}, "children": [] }
>> But unfortunately we can't go grabbing data hierarchically without 
>> doing a pile of queries, or complicating the data structure in a way 
>> that I cannot sanely complicate the program itself by using when I 
>> have other options. Avoiding the huge piles of queries and 
>> overcomplicated data structures was the whole reason behind moving 
>> away from MySQL and into using non-traditional databases.
>>
>> In the XML database instead of the structure before I can place all 
>> the jits into one document for the site (because I can modify 
>> individual parts of it without worrying about conflicts in other 
>> parts of the document) and make use of XQuery to to iteration and 
>> recursion and return whatever I need.
>> <site id="...">
>> <jits>
>> <jit 
>> id="aaa"><state/><children><jit>bbb</jit><jit>ccc</jit></children></jit>
>> <jit id="bbb"><state/><children><jit>ddd</jit></children></jit>
>> <jit id="ccc"><state/><children><jit>ddd</jit></children></jit>
>> <jit id="ddd"><state/><children/></jit>
>> </jits>
>> </site>
>
> I'm confused I think. Is it correct to say that you compile all jits 
> into a master document per site? What would prevent you from using the 
> same technique with CouchDB?
Dealing with whole documents at once.
To modify a small part of a single Jit, one would need to download the 
entire document, modify that small chunk of data, then PUT that entire 
document back to the server.
It leads to the conflict issue where you have to deal with the fact that 
someone might have modified a completely irrelevant part of the document 
in the meantime and you hit a conflict as a result.
It's also extremely inefficient since you have to transfer (twice) and 
handle a document that may contain thousands of Jits just to modify a 
tiny piece of it. Not to mention the duplication of the document every 
time you make a minor modification.
>> So querying for the jit ID by document id in couch is equivalent to 
>> `doc(...)/site/jits/jit[id="..."]` in XQuery. But because of FLWOR 
>> and the other parts of XQuery I should theoretically be able to deal 
>> with the recursive nature of our data on the database side.
>
> I think you can do the very same thing in CouchDB using one doc per 
> site. You can use views to generate the recursive list of jits you 
> need to load.
>
> As for atomicity, a document is atomic for CouchDB, so that would help 
> as well?
>
> Wout.
>
Views are actually fairly wasteful on memory for tasks which aren't to 
heavy on the CPU to do at query time. Especially since to index an 
entire document with a view you basically duplicate it a pile of times.

~Daniel Friesen (Dantman, Nadir-Seen-Fire)


Mime
View raw message