What is the most cost-effective way to break up a centralised database?

Question

Following on from this question...

• What to do when you’ve really screwed up the design of a distributed system?

... the client has reluctantly asked me to quote for option 3 (the expensive one), so they can compare prices to a company in India.

So, they want me to quote (hmm). In order for me to get this as accurate as possible, I will need to decide how I'm actually going to do it. Here's 3 scenarios...

Scenarios

Split the database

My original idea (perhaps the most tricky) will yield the best speed on both the website and the desktop application. However, it may require some synchronising between the two databases as the two "systems" so heavily connected. If not done properly and not tested thouroughly, I've learnt that synchronisation can be hell on earth.

Implement caching on the smallest system

To side-step the sync option (which I'm not fond of), I figured it may be more productive (and cheaper) to move the entire central database and web service to their office (i.e. in-house), and have the website (still on the hosted server) download data from the central office and store it in a small database (acting as a cache)...

1. Set up a new server in the customer's office (in-house).
2. Move the central database and web service to the new in-house server.
3. Keep the web site on the hosted server, but alter the web service URL so that it points to the office server.
4. Implement a simple cache system for images and most frequently accessed data (such as product information).

... the down-side is that when the end-user in the office updates something, their customers will effectively be downloading the data from a 60KB/s upload connection (albeit once, as it will be cached).

Also, not all data can be cached, for example when a customer updates their order. Also, connection redundancy becomes a huge factor here; what if the office connection is offline? Nothing to do but show an error message to the customers, which is nasty, but a necessary evil.

Mystery option number 3

Suggestions welcome!

SQL replication

I had considered MSSQL replication. But I have no experience with it, so I'm worried about how conflicts are handled, etc. Is this an option? Considering there are physical files involved, and so on. Also, I believe we'd need to upgrade from SQL express to SQL non-free, and buy two licenses.

Technical

Components

• ASP.Net website
• ASP.net web service
• .Net desktop application
• MSSQL 2008 express database

Connections

• Office connection: 8 mbit down and 1 mbit up contended line (50:1)
• Hosted virtual server: Windows 2008 with 10 megabit line

Answer 1

Having just read for the first time your original question related to this I'd say that you may have laid the foundation for resolving the problem simply because you are communicating with the database by a web service.

This web service may well be the saving grace as it allows you to split the communications without affecting the client.

A good while back I was involved in designing just such a system.

The first thing that we identified was that data which rarely changes - and immediately locked all of this out of consideration for distribution. A manual process for administering using the web server was the only way to change this data.

The second thing we identified was that data that should be owned locally. By this I mean data that only one person or location at a time would need to update; but that may need to be viewed at other locations. We fixed all of the keys on the related tables to ensure that duplication could never occur and that no auto-incrementing fields were used.

The third item was the tables that were truly shared - and although we worried a lot about these during stages 1 & 2 - in our case this part was straight-forwards.

When I'm talking about a server here I mean a DB Server with a set of web services that communicate between themselves.

As designed our architecture had 1 designated 'master' server. This was the definitive for resolving conflicts.

The rest of the servers were in the first instance a large cache of anything covered by item1. In fact it wasn't a large cache but a database duplication but you get the idea.

The second function of the each non-master server was to coordinate changes with the master. This involved a very simplistic process of actually passing through most of the work transparently to the master server.

We spent a lot of time designing and optimising all of the above - to finally discover that the single best performance improvement came from simply compressing the web service requests to reduce bandwidth (but it was over a single channel ISDN, which probably made the most difference).

The fact is that if you do have a web service then this will give you greater flexibility about how you implement this.

I'd probably start by investigating the feasability of implementing one of the SQL server replication methods

Usual disclaimers apply: