incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hood <0x6e6...@gmail.com>
Subject Re: Temporal data
Date Sun, 08 Mar 2009 20:01:18 GMT
Jason,

On Sun, Mar 8, 2009 at 6:59 PM, Jason Smith <jhs@proven-corporation.com> wrote:
> So my approach would be to exploit the guarantee of coherence that you get
> from the file format.  If I absolutely had to have this feature now, I would
> look into using LVM to snapshot the filesystem.  That gives you a fresh
> read-only mountpoint of your snapshotted filesystem.  From there, you can
> copy the couch data files to a backup location, either regularly via cron,
> or the app could trigger the process.

Yes, I was thinking along the lines of ZFS send/receive instead of LVM
snapshots, but both approaches seem equivalent.

> Whenever you want to see old document versions, you just start a new couchdb
> process on a different port running against one of the backups and you query
> it normally.  Since access to the DB is just via a URL, it shouldn't be too
> bad to change the port number in your app.
> Does that make sense?

Yes. Does it have to be as coarse grained as starting a new Couch
instance, or can I start a new view process in an existing Couch
instance that boots a new DB instance of the file handle to the
snapshot mountpoint?

> (Honestly it may be easier to putting version metadata in the documents, but
> I guess if you had lots of different document types it may save code to do
> it with the OS instead, at a cost of making your app less portable and use
> more disk space.  Also, none of this is necessarily CouchDB-related.  You
> could do the same thing with MySQL I suppose.)

This is true, you can always code this into the app - I was just
investigating whether I could possibly get anything for free :-)

Another advantage of doing this in the app layer as opposed to
misusing Couch's internal versioning is that you avoid losing data via
a compaction.

Furthermore, though I wouldn't consider portability to be such an
issue from an application's perspective (as opposed to a product
perspective), using functionality outside of the VM makes the whole
thing less self-contained. (Having said that, Couch is not a 100%
Erlang application anyway).



Ben

Mime
View raw message