Databases Reference
In-Depth Information
Chapter 10
Federations
One of the major tenets of any cloud computing platform is elasticity, allowing systems to scale beyond certain
limits of their current designs. With Federations, SQL Database delivers on that promise; it is a technology your SQL
Database instances can use to scale over time based on size or performance bottlenecks.
You may have certain expectations about how this technology should work, one of which is likely to be
transparency to your applications. You may expect that no code changes should be necessary to your existing
applications if you were to use Federations. Like anything else, radical features like Federations come with certain
compromises. Considering that this is the first incarnation of Microsoft's answer to scaling out the database tier, you
will need to account for certain limitations before you can reap the benefits. This chapter will help you understand
what problems Federations answer and how to best leverage this feature.
Introducing Federations
Until now, the only practical way developers and administrators could improve the performance and scalability of
a database that needs both read and write access, without introducing significant code changes, was to add more
memory, more CPU, or more disks on the same server. This is referred to as “scaling up.” The Federation feature was
introduced on the SQL Database platform with the intent of solving the scalability issues of traditional database
servers; it provides a way to “scale out” a database by adding more servers to your database.
Federations versus Sharding
In the database world, sharding is a general term describing the distribution of highly related data across multiple
physical machines. As a result, sharding is the implementation of a scale-out architecture used by large databases in
order to harness the computing power of multiple machines. Federations are SQL Database's implementation of the
sharding concept. To explain where Federation fits in the big picture, I'll outline the various scaling models available.
The scaling models described below are architected around the concept of a
data domain
, which is the primary unit
of data segregation used in a shard. For example, in most commercial applications the data domain is the customer. In
astronomy the data domain could be a galaxy, or a planet. In finance, it could be the fiscal year.
•
Scale Up
. As described previously, scale-up architecture involves adding more resources to a
machine holding data. The fundamental issue with scale-up architecture is that at some point
adding more resources on a server doesn't yield better performance, because the application
is not designed to account for all the available resources, and the law of diminishing returns
applies. All the data domain instances are stored in the same database, and every query needs
to include the data domain it is using (such as a
WHERE
clause when searching for a specific
customer ID). This is the architecture used by most systems.
