Database Reference
In-Depth Information
Horizontal partitions
Mirror
databases based on the available
connection. No logic can be applied to
determine which database contains
which records.
Create
: Insert a record in the current
database.
Read
: Connect to all databases, issue
statements, and concatenate
resultsets. Add breadcrumbs for
update and delete operations.
Update
: Connect to all databases (or
use breadcrumbs), and apply updates
using a primary ke.
Delete
: Same as update.
Use a single database (called the
primary database
) for writes.
Create
: Insert a record in the primary
database only.
Read
: Connect to any database in a
round-robin fashion.
Update
: Update a record in the
primary database only.
Delete
: Delete a record in the primary
database only.
Shards can be very difficult to implement. Make sure you test thoroughly when implementing
shards. You can also look at some of the shard libraries that have been developed. The shard library
found on CodePlex and explained further in this topic (in Chapter 10) uses .NET 4.0; you can find it with
its source code at
http://enzosqlshard.codeplex.com
. It uses round-robin as its access method. You can
also look at another implementation of a shard library that uses
SQLAzureHelper
; this shard library uses
decision rules as its access method and is provided by the SQL Azure Team
(
http://blogs.msdn.com/b/sqlazure/
).
Read-Only Shards
Shards can be implemented in multiple ways. For example, you can create a read-only shard (ROS).
Although the shard is fed from a database that accepts read/write operations, its records are read-only
for consumers.
Figure 2-8 shows an example of a shard topology that consists of a local SQL Server to store its data
with read and write access. The data is then replicated using the SQL Data Sync framework (or other
method) to the actual shards, which are additional SQL Azure databases in the cloud. The consuming
application then connects to the shard (in SQL Azure) to read the information as needed.
