incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sleepy <wanpee...@gmail.com>
Subject Re: multi columns
Date Thu, 04 Nov 2010 07:58:47 GMT
Nice discussion here!

I have thought about this kind of design, but thus I need to get a
searchable indexed View from that View which is not possible in
current CouchDB design.

However, I still think to manage data as small change sets like Git
is the way to go. It fits the immutable structure of the CouchDB
internal very well because changes are immutable, too.

Thus, the entire database become a data evolution log can be
play back or rewind at anytime.

I think CouchDB should consider this kind of design seriously.

-sleepnova

2010/11/4 Randall Leeds <randall.leeds@gmail.com>

> On Wed, Nov 3, 2010 at 11:54, Mark J. Reed <markjreed@gmail.com> wrote:
> >
> > Anyway, CouchDB doesn't have this feature.  I disagree with sgoto that
> > the crash-only design prohibits it, however. Certainly the server
> > would have to append the entire modified record to the data store, but
> > that doesn't mean the entire document has to go over the wire back and
> > forth between the server and the client.  As long as the modification
> > was anchored to a specific _rev, it would just be shorthand for the
> > GET, PUT sequence currently required.
> >
>
> With the durability guarantees from Couch there are two options:
> 1) Always re-write the whole document ("row")
> 2) Deal with document fragmentation. If I recall correctly, this is
> why range queries over super-columns in Cassandra can be very slow.
>
> It'd be a deep change to support this kind of behavior. You may want
> to consider breaking your documents up into pieces and using a view to
> reconstruct the fully denormalized documents.
>
> -Randall
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message