couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <jch...@grabb.it>
Subject Re: Proper Database Design and View Collation
Date Sat, 06 Sep 2008 20:03:01 GMT
Brian,

I finally had the time to dive in and find some answers for you.

I wrote code, and it's here:
http://github.com/jchris/couchdb-reduce-example

If you have access to Ruby it should be really self explanatory to
tryout. I took the Zen approach of changing the question is subtle
ways to better fit the CouchDB paradigm.

On Wed, Sep 3, 2008 at 5:50 PM, Brian Troutwine
<goofyheadedpunk@gmail.com> wrote:
> Currently an attempt is made once per hour, though the connection to
> an individual device is tenuous as best, so information concerning the
> last attempted retrieval and the last successful retrieval must be
> stored. Additionally, each sensor has a number of static attributes
> which I also store in CouchDB, such as the sensor's unique ID and GPS
> coordinates.
>
> I represent each sensor as a single document in CouchDB, storing the
> readings as documents, with timestamps, in a list. Here's an example:

The biggest change in my approach is that I have one master document
for each sensor. This doc has the sensor id, and it's description.
This is also where you'd put the lat/long and other sensor metadata.

Each reading is stored in its own document. Currently, I only simulate
one value per sensor. We can pretend that it's always temperature, or
something. My approach should generalize to multiple reading types,
easily enough.


> I have four views: get_new_attempts, find_unresponsive,
> find_malfunctioning and last_reading. The first two are simple, they
> compare the last_attempt and last_update fields, respectively, to the
> current date, emitting sensor_id and coordinate. The third requires
> computing the standard deviation of the temperature, pressure and
> humidity measurements of all readings and emits the sensor_id of that
> sensor which has more than a fixed, acceptable deviation. As all the
> readings are stored in the sensor document this computation is,
> currently, a straight-forward iteration. The last creates emits the
> sensor_id as key and the data reading with the largest time_gathered
> as value.

I changed the question, with my query document printing out the most
recent reading from each sensor, along with its timestamp (and how
long ago that was in minutes). You can decide which sensors need to be
queried, by how long ago their most recent reading was. I didn't do
anything with failed reading attempts, although you should create
documents for readings that fail, also, and then you could easily get
a view of sensors who's last attempt was a failure.

The std-deviation part was more interesting. I lifted Damien's view
code directly from the Futon test suite, for calculating
std-deviation. The interesting part about what I did was setting up
the queries to get back the std-dev for all sensors in one request.
It's all there in the query.rb file.

I hope this helps. I might turn it into a blog post when I have the inclination.

-- 
Chris Anderson
http://jchris.mfdz.com

Mime
View raw message