Multi-Tenant Approach

4,488 views

Published on

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.

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,488
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
234
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Multi-Tenant Approach

  1. 1. Multi-Tenant Approach Perfectial, LLC info@perfectial.com
  2. 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. 3. Multi-tenant data approaches • Separate database • Separate schema • Partitioned (discriminator) data • Data sharding
  4. 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. 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. 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. 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. 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. 9. Federations structure
  10. 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. 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. 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. 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. 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. 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. 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. 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. 18. Perfectial, LLC http://perfectial.com info@perfectial.com

×