Multi-Tenant Approach

Perfectial, LLC

info@perfectial.com

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.

Multi-tenant data approaches

• Separate database

• Separate schema

• Partitioned (discriminator) data

• Data sharding

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.

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.

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.

Data shardingSharding 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.

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’.

Federations structure

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.

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)

Federation memberThe 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

Split federationThe ALTER FEDERATION is used to split a federation member and to drop a

federation member.

ALTER FEDERATION <FederationName> SPLIT AT (<DistributionKeyName>=<splitpoint>)

Drop federationThe ALTER FEDERATION is used to split a federation member and to drop a

federation member.

ALTER FEDERATION <FederationName> DROP AT ([LOW|HIGH] <DistributionKeyName> = <value>)

Creating a federation and a federated table

CREATE FEDERATION CustomerFederation(cust_id BIGINT RANGE)GOUSE FEDERATION CustomerFederation(cust_id=1) WITH RESET, FILTERING=OFFGOCREATE 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

Table types• FederatedFederated 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.

• ReferenceReference 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.

• CommonCommon 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.

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• …

Perfectial, LLChttp://perfectial.com

info@perfectial.com