couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Govind P <p.govind....@gmail.com>
Subject Re: Couch DB Deployment
Date Wed, 31 Mar 2010 02:07:12 GMT
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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message