Database – Is the database the bottleneck or not? High Scalability talk

Here is a list of standard options.

1. Optimize the access to the database to only do what you need, efficiently. A good DBA can help here a lot. This is a basic step that most companies do.

2. Cache data away from the database using something like memcached. This is usually done at the application layer, and is highly effective. Virtually every competent website should do this.

3. More ambitiously, maintain read-only copies of the database, and direct queries there when possible. On the database side the necessary technology is called "replication" and the read-only copies are often also backups for failover from the main database. If you're doing a million dynamic pages per hour, odds are that you are doing this, or have thought about it.

4. Buy really, really expensive hardware for the database. I know that PayPal did this as of 4 years ago, and changing their architecture would have been difficult so they possibly still are.

5. Shard the database into multiple pieces with ranges of data. This is a very intrusive change into application design. A well-known example of a company that does this is eBay.

6. Try to use a database that scales onto multiple machines. Oracle RAC scales onto clusters, but doesn't let you distribute data widely. Other offerings exist that are supposed to be easier to distribute, including Microsoft's SQL Azure and FathomDB. I have not used those offerings and don't know how well they work. I suspect better than nothing, but I doubt they scale horizontally that well.

7. Relational databases generally try to provide ACID guarantees. But the CAP theorem makes it very difficult to do that in a distributed system, particularly while letting you do things like join data. Therefore people have come up with many NoSQL alternatives that explicitly offer weaker guarantees and avoid problematic operations in return for fully distributed scalability. Well-known examples of companies that use scalable NoSQL data stores include Google, Facebook and Twitter.

I think ultimately what you are looking for is an explanation of different ways that SQL Server can be utilized to handle extremely large tables and data sets being replicated across the database server instances. There are multiple approachs to this problem and none of them are a silver bullet, but understanding the basics of each is a good way to make the right architecture choice.

Sharding

Database sharding is a way to take an enormous data set and partition it into a number of different file groups. These individual filegroups can be stored all on a single server, multiple servers, or better yet through a RAID based Storage Area Network.

The bottom line here is that physical IO performance significantly improves when you are accessing records from only a few physical file groups than from an enormous filegroup in an unsharded dataset.

SQL Server does not have a cheap or easy way to do this out of box, nor do I know of any easy or cheap way to do this with other major database providers. Once you start talking about shards then you are playing a different ball game altogether.

Distributed Partition Views

These enable well partitioned datasets to be accessed in such a way that one would only fetch the necessary records based on your partitioning strategy. There is good information on MSDN about this with SQL Server.

Active Clustering

The concept of clustering is to take multiple SQL Server instances as nodes and have them work together on a single database, synchronized so that partitions on different file groups are being read and written to in a way that does not corrupt or damage the data, and in a way that scale up massively.

Peer to Peer Replication

In this setup all database servers have their own instance, and each should be configured to only affect their own little area of the schema. Data is frequently out of date between them and needs to be synced through some outside process and schema changes can be extremely difficult to implement. This is not the ideal way to handle this in your application.

I can't afford distributed partitions and massively scalable active clustering!

So you don't have upwards of a million to drop on some licenses and hardware for massively scalable solutions? There is always the Cloud. Azure and other SQL Server PaaS (Platform as a Service) solution providers can provide you the scalability that you need without the large upfront investment. This is generally the easiest route to go.