The presentation is about multi-tenant architecture and the approaches of managing multi-tenant data. It describes SQL Azure Federation technology which allows to design one of the approaches - data sharding. Several examples of SQL commands show you how the data can be partitioned and how you can access and manage it.

1. Multi-Tenant Approach
Perfectial, LLC
info@perfectial.com

2. What is multi-tenancy ?
Multi-tenancy is an architecture in which a single instance of a software
application serves multiple customers.
Each customer is called a TENANT.
Tenants may be given the ability to customize some parts of the application,
such as color of the user interface (UI) or business rules, but they cannot
customize the application's code.
A software-as-a-service (SaaS) provider, for example, can run one instance
of its application on one instance of a database and provide web access to
multiple customers. In such a scenario, each tenant's data is isolated and
remains invisible to other tenants.

3. Multi-tenant data approaches
• Separate database
• Separate schema
• Partitioned (discriminator) data
• Data sharding

4. Separate database
Computing resources and application code are generally shared between all
the tenants on a server, but each tenant has its own set of data that remains
logically isolated from data that belongs to all other tenants.

5. Separate schema
Shared Database, Separate Schemas
This approach involves housing multiple
tenants in the same database, with each
tenant having its own set of tables that
are grouped into a schema created
specifically for the tenant.

6. Partitioned data
Shared Database, Shared Schema
In this approach, all tenants share the same set of
tables, and a Tenant ID associates each tenant with
the rows that it owns.

7. Data sharding
Sharding is a type of database partitioning that separates very large
databases the into smaller, faster, more easily managed parts called data
shards. The word shard means a small part of a whole.
Technically, sharding is a synonym for horizontal partitioning. In practice, the
term is often used to refer to any database partitioning that is meant to make
a very large database more manageable.
Simple example is splitting a customer database geographically. Customers
located on the East Coast can be placed on one server, while customers on
the West Coast can be placed on a second server.
Long story short: Sharding is basically the process of distributing tables into
different servers in order to balance the load equally.

8. SQL Azure Federations
Federations in Windows Azure SQL Database (SQL Database) are a way to
achieve greater scalability and manage capacity limitations in the database
tier of your application.
One or more tables within a database are horizontally partitioned across
multiple databases called federation members. This type of horizontal
partitioning is often referred to as ‘sharding’.

9. Federations structure

10. Federation Root Database
The federation root database is a SQL Azure database that contains metadata
about the federations.
CREATE DATABASE [fedRoot] COLLATE French_CI_AS (MAXSIZE = 100 GB, EDITION = 'business')
Any federations you create will inherit the properties of the root database.

11. Federation
The federation is where you define the data type (e.g., Customer ID, Product
ID) you’ll shard on.
CREATE FEDERATION <FederationName>(<DistributionKeyName> <DistributionType> RANGE)
<FederationName> is the name of the federation
<DistributionKeyName> is the name for the distribution key, and
<DistributionType> is the distribution data type that data will be sharded on.
The valid distribution data types are:
- int
- bigint
- uniqueidentifier
- varbinary (up to 900)

12. Federation member
The federation member is the shard (i.e., the database containing a specific
range of information). By default, a created federation contains one
federation member with a range of low to high (containing all the data).
Connect to federation member:
USE FEDERATION <federation_name>(<distribution_name> = value) WITH FILTERING={ON|OFF}, RESET
Connect to Root:
USE FEDERATION ROOT WITH RESET

13. Split federation
The ALTER FEDERATION is used to split a federation member and to drop a
federation member.
ALTER FEDERATION <FederationName> SPLIT AT (<DistributionKeyName>=<splitpoint>)

14. Drop federation
The ALTER FEDERATION is used to split a federation member and to drop a
federation member.
ALTER FEDERATION <FederationName> DROP AT ([LOW|HIGH] <DistributionKeyName> = <value>)

15. Creating a federation and a
federated table
CREATE FEDERATION CustomerFederation(cust_id BIGINT RANGE)
GO
USE FEDERATION CustomerFederation(cust_id=1) WITH RESET, FILTERING=OFF
GO
CREATE TABLE [dbo].[Customer](
[CustomerID] [bigint] NOT NULL,
[Title] [nvarchar](8) NULL,
[FirstName] [nvarchar](50) NOT NULL,
[LastName] [nvarchar](50) NOT NULL,
[CompanyName] [nvarchar](128) NULL,
[EmailAddress] [nvarchar](50) NULL,
[ModifiedDate] [datetime] NOT NULL,
CONSTRAINT [PK_Customer_CustomerID] PRIMARY KEY CLUSTERED
(
[CustomerID] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF)
)FEDERATED ON (cust_id=CustomerID)
GO

16. Table types
• Federated
Federated tables contain the data that is federated across each federation
member. When the federation member is split, this data is distributed among
the two new federation members. A federated table is created by appending
FEDERATED ON to a CREATE TABLE statement.
• Reference
Reference tables are normal tables existing in each federation member and
their contents are copied to the new federation members formed when an
existing federation member is split.
• Common
Common tables are normal tables existing in the root database. They would
be typically be used for application data that does not need to be present in
each federation member.

17. Dynamic Management Views
There are various DMVs to support the management and use of SQL Azure
Federations:
• sys.federations
• sys.federation_members
• sys.federation_distributions
• sys.federation_member_distributions
• sys.federation_history
• sys.federation_member_history
• sys.federation_distribution_history
• sys.federation_member_distribution_history
• …

18. Perfectial, LLC
http://perfectial.com
info@perfectial.com