Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of p.govind.raj@gmail.com
 designates 209.85.221.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=AIoiOzNDKC5VsuIeLTG2/C7ZzBj0gB9Ildg7d1PkW2pwao9r3jAIvB5HU/qaLdYwnR
         eOzyJ9DSsjGQJsHrYUsSzzlYfB580WxtN2KvZnnUTi74pgT1vMEJ1u1qZxF0g1cTaOWL
         ZyZzAK40wlAt57fAi/KFQMLij8SLNBjuvMQts=
MIME-Version: 1.0
In-Reply-To: <75FC82F0-8653-4465-8C7D-D9D889B96D4A@apache.org>
References: <4ab4006d1003281133w71c1a3efy194e626b20dfa6c6@mail.gmail.com>
	<BBD681A6-1BC2-4FBD-84D7-F068DA226EF1@gmail.com>
 <4ab4006d1003281809h4b01fd40v42c07c3566453cce@mail.gmail.com>
	<75FC82F0-8653-4465-8C7D-D9D889B96D4A@apache.org>
From: Govind P <p.govind.raj@gmail.com>
Date: Wed, 31 Mar 2010 07:37:12 +0530
Message-ID: <4ab4006d1003301907t5a65b527id72c331c088a41c4@mail.gmail.com>
Subject: Re: Couch DB Deployment
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=0016363b86a882aab104830f35aa

--0016363b86a882aab104830f35aa
Content-Type: text/plain; charset=ISO-8859-1

Hi ,


In the architecture below what would be the advantages and disadvantages if
we MySQL Geographic Replication instead of CouchDB.

Regards
Govind

On 29 March 2010 08:00, Jan Lehnardt <jan@apache.org> wrote:

> 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
> >>
> >>
>
>

--0016363b86a882aab104830f35aa--