Database Reference
In-Depth Information
Based on these principles, there are two options for building transaction application
that can scale out using SQL Azure. The first option is to store the data in multiple
groups where each table group can fit comfortably on a single machine. In this
scenario, the application takes the responsibility for scaling out by partitioning the
data into separate table groups. The second option is to design the database as keyed
table group so that the SQL Azure can perform the scale out process automatically.
In SQL Azure, the
consistency unit
of an object is the set of data that can
be read and written by an ACID transaction. Therefore, the consistency unit of a
keyed table group is the row group while the consistency unit of a keyless table
group is the whole table group. Each replica of a consistency unit is always fully
contained in a single instance of SQL server running one machine. Hence, using
the two-phase commit protocol is never required. A query can execute on multiple
partitions of a keyed table group with an isolation level of read-committed. Thus,
data that the query read from different partitions may reflect the execution of
different transactions. Transactionally consistent reads beyond a consistency unit
are not supported.
At the physical level, a keyed table group is split into partitions based on ranges
of its partitioning key. The ranges must cover all values of the partitioning key
and must not overlap. This ensures that each row group resides in exactly one
partition and hence that each row of a table has a well-defined home partition.
Partitions are replicated for high availability. Therefore, a partition is considered
to be the failover unit. Each replica is stored on one server. Since a row group is
wholly contained in one replica of each partition that is scattered across servers
such that no two copies reside in the same
failure domain
. To attain high availability
on unreliable commodity hardware, the system replicates data. The transaction
commitment protocol requires that only a quorum of the replicas be up. A Paxos-
like consensus algorithm is used to maintain a set of replicas to deal with replica
failures and recoveries. Dynamic quorums are used to improve availability in the
face of multiple failures. In particular, for each partition, at each point in time one
replica is designated to be the primary. A transaction executes using the primary
replica of the partition that contains its row group and thus is non-distributed. The
primary replica processes all query, update, and data definition language operations.
The primary replica is also responsible for shipping the updates and data definition
language operations to the secondary replicas.
Since some partitions may experience higher load than others, the simple tech-
nique of balancing the number of primary and secondary partitions per node might
not balance the loads. The system can rebalance dynamically using the failover
mechanism to tell a secondary on a lightly loaded server to become the primary
by either demoting the former primary to secondary or moving the former primary
to another server. A keyed table group can be partitioned dynamically. If a partition
exceeds the maximum allowable partition size (either in bytes or the amount of
operational load it receives), it is split into two partitions. In general, the size of
each hosted SQL Azure database can not exceed the limit of 50 GB.
