Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of robert.newson@gmail.com
 designates 74.125.82.180 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: versioning for sensors data storage
From: Robert Newson <robert.newson@gmail.com>
In-Reply-To: 
 <CALp=RoXBFOyAoh4KW-ioODhOE3WPm7WQA1fFECz9Zyrob1t9LA@mail.gmail.com>
Date: Sat, 9 Jun 2012 06:52:48 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <233494A3-4F5E-4BF8-8094-DB66174B97A8@gmail.com>
References: 
 <CALp=RoXBFOyAoh4KW-ioODhOE3WPm7WQA1fFECz9Zyrob1t9LA@mail.gmail.com>
To: dev@couchdb.apache.org

user@ please.

On 8 Jun 2012, at 12:08, Maxim Osipov wrote:

> Hi,
> 
> Warning: I'm new to CouchDB! And I'm in a process pf selecting a
> database to store data from sensors. The scenario looks like this:
> 
> There are sensors on the net (may be thousands or later millions) for
> things like temperature, motion, etc. Each sensors has an IPv6 address
> and pushes data to central server in JSON format, like:
> { temp: 36.6; humidity: 80 }
> We don't know in advance what exactly sensor will push, but most of
> the time the format of JSON structure is the same. Data is updated ...
> say every second for each sensor.
> 
> From the "architecture" point of view it could be a nice solution with
> CouchDB, where each sensor is represented by a document and each
> sample of sensor data is a version of this document.
> 
> The questions are:
> - do we have time/date information for versions
> - is it easy/good to access document version history
> - what is a limit on number of versions and how it affects performance
> - is it possible/easy/good to get a time snapshot of database
> 
> All other comments are also welcome!
> 
> Kind regards,
> Maxim
> 
> -- 
> Maxim Osipov
> Flexibity Ltd.