Database Reference
In-Depth Information
Figure 2-8.
Read-only shard topology
In one scenario, the SQL Azure databases each contain the exact same copy of the data (mirror
shard), so the consumer can connect to one of the SQL Azure databases (using a round-robin
mechanism to spread the load, for example). This is perhaps the simpler implementation because all the
records are copied to all the databases in the shard blindly. However, keep in mind that SQL Azure
doesn't support distributed transactions; you may need to have a compensating mechanism in case
some transactions commit and others don't.
Another implementation of the ROS consists of synchronizing the data using horizontal
partitioning. In a horizontal partition, rules are applied to determine which database contains which
data. For example, the SQL Data Synch service can be implemented to partition the data for US sales to
one SQL Azure database and European sales to another. In this implementation, either the consumer
knows about the horizontal partition and knows which database to connect to (by applying decision
rules based on customer input), or it connects to all databases in the cloud by applying a
WHERE
clause on
the country if necessary, avoiding the cost of running the decision engine that selects the correct
database based on the established rules.
Read-Write Shards
In a read-write shard (RWS), all databases are considered read/write. In this case, you don't need to use
a replication topology that uses the SQL Data Sync framework because there is a single copy of each
record within the shard. Figure 2-9 shows a RWS topology.
Although a RWS removes the complexity of synchronizing data between databases, the consumer is
responsible for directing all CRUD operations to the appropriate cloud database. This requires special
considerations and advanced development techniques to accomplish, as previously discussed.
