couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Couch DB Deployment
Date Mon, 29 Mar 2010 02:30:12 GMT
Hi Govind,

On 28 Mar 2010, at 18:09, Govind P wrote:

> Hi ,
> 
> Just wanted to have an opinion on the deployment architecture .....
> 
> 
> Is the deployment strategy used in Use Case an apt one .  We have placed
> couchDB at each Parcel Tracking Centre and they sync to the Data Centre.
> They don;nt Sync with each other. This is done as the size of the Database
> would be too large at Parcel Tracking Centre and we do not want to keep
> machines with large storage in Parcel Tracking centres.
> 
> Please suggest if things needs be done differently.

this sounds sensible to me. If you'd replicate all documents to all parcel centres,
you'd have to double the IT infrastructure for each centre. I don't think you want
that :)

You could allow though for nearby* parcel centres to replicate their data too, so
nearby updates could be tracked without round tripping to the central data centre.

* Nearby would mean parcel centres that parcels pass through on their delivery,
if you have common routes, not necessarily geographically nearby.

Cheers
Jan
--




> 
> 
> Regards
> Govind
> 
> On 29 March 2010 01:08, J Chris Anderson <jchris@gmail.com> wrote:
> 
>> 
>> On Mar 28, 2010, at 11:33 AM, Govind P wrote:
>> 
>>> Hi ,
>>> 
>>> I am considering using CouchDB in one of our projects. This project is
>>> already in production.
>>> 
>>> This project is about tracking parcels across Postal Networks. The postal
>>> networks has got various postal centres through which the parcel moves
>>> before reaching it's final destination. In the earlier design all the
>> Postal
>>> Centres were connected to a data centre and these Postal Centres would
>>> update the current Status of parcel in the Data Centre. End Users could
>>> query an application hosted at Data Centre to track their parcels.
>>> 
>>> One of the problem is that the network between Postal Centre and the Data
>>> Centre is fragile and keeps on disconnecting... Therefore i was thinking
>> of
>>> using Couch DB in each of these Postal Centres and replicating this with
>> the
>>> Data Centre. This way when the network comes up at a particular Postal
>>> Centre , it sync it's data with the Data Centre. I would like you to
>> comment
>>> whether this would work.
>>> 
>>> I have couple of scenarios , for which I need your advice :
>>> 
>>> 
>>>  1. Let there be a Postal Centres A (Source), B ,C and D(Destination )
>>>  through which a parcel moves. When the parcel moves to A ,an
>> application
>>>  program running at A updates CouchDB at the local centre which is
>> replicated
>>>  at the Data Centre. The Parcel is now send to B. Now , the network
>> between B
>>>  and Data Centre is disconnected. So only the local copy of B is updated
>> and
>>>  not the Data Centre. The parcel is now send to C . Here the local
>> CouchDB at
>>>  C and the Data Centre is Connected so the changes made in CouchDB is
>> also
>>>  replicated at the Data Centre. If now B comes up , would there be a
>> conflict
>>>  situation ... If yes , how can we manage this situation ????
>> 
>> When modeling something where you expect concurrent updates, it's often
>> helpful to split something into a few documents. In this case I might have a
>> Parcel document, and then Tracking documents, one for each time a parcel is
>> seen at a different Post Office.
>> 
>> This way if updates are received out of order, or otherwise conflict, they
>> will still be visible to the user.
>> 
>>>  2. Let there be a Postal Centres A (Source), B ,C and D(Destination )
>>>  through which a parcel moves. When the parcel moves to A ,an
>> application
>>>  program running at A updates CouchDB at the local centre which is
>> replicated
>>>  at the Data Centre. The Parcel is now send to B. Now , the local
>> application
>>>  is down because of a machine failure so no updation is made in the
>> software
>>>  at the local site and the parcel is send to C.Here the local CouchDB at
>> C
>>>  and the Data Centre is Connected so the changes made in CouchDB is also
>>>  replicated at the Data Centre. Now B Comes up and people make changes
>> in
>>>  CouchDB at B .. There might be conflicts here too.. How can we manage
>> this
>>>  situation ????
>> 
>> In this case, if users see a screen like (can be composed in a single view
>> query):
>> 
>> Parcel: info, etc
>> Destination: Post Office C
>> 
>> Tracking events:
>> 
>> Post Office A: seen at 10:15am
>> Post Office C: seen at 8:30pm
>> Post Office B: Missing package alert at 9pm
>> 
>> A screen like this makes it clear that B's report can be disregarded.
>> 
>> Chris
>> 
>> 
>> 
>> 
>>> 
>>> 
>>> Regards
>>> Govind
>> 
>> 


Mime
View raw message