Transcript Federation Member

МАСШТАБИРУЕМОСТЬ
SQL SERVER И SQL AZURE
Теория и практика
Денис Резник
[email protected]
О себе
Руководитель департамента веб-разработки компании Digital Cloud
Technologies
Тренер Microsoft Innovation Center
Microsoft MVP (SQL Server)
Microsoft Certified Trainer
USSUG Lead
Блог: http://reznik.uneta.com.ua
Твиттер: @DenisReznik
Email: [email protected]
Track # – Session #
2
Possible text here
Масштабирование
v
Масштабирование
Способность справляться с увеличением
нагрузки без влияния на производительность
Высокая доступность и отказоустойчивость
Управляемость и сопровождаемость
Track # – Session #
4
Вертикальное масштабирование
Scale Up
Купить мощный сервер
Добавлять серверу ресурсы
Есть потолок масштабируемости
Track # – Session #
5
Вертикальное масштабирование
SQL Server
Горячее добавление памяти и процессоров
Поддержка до 256 ядер
Track # – Session #
6
Вертикальное масштабирование
SQL Azure
Scale Up в SQL Azure нет!
32 GB RAM, 8 cores
Track # – Session #
7
Горизонтальное масштабирование
Scale Out
Распределить данные и нагрузку между
несколькими серверами
Способность противостоять пиковым
нагрузкам
Не имеет границ масштабирования
Track # – Session #
8
Горизонтальное масштабирование
SQL Server
Распределить данные и нагрузку между
несколькими серверами
Способность противостоять пиковым нагрузкам
Не имеет границ масштабирования
Track # – Session #
9
Горизонтальное масштабирование
База данных
Варианты масштабирования базы данных
Репликация
Дублирование данных на серверах
Шардинг
Распределение данных между серверами
Track # – Session #
10
Репликация
v
Master-Slave репликация
Пишем на Master, читаем со Slave-ов
Масштабирование чтения
Запись не масштабируюется
Блокировки на всех серверах
Track # – Session #
12
Peer-to-Peer репликация
Пишем на все сервера
Читаем со всех серверов
Синхронизация данных
Track # – Session #
13
AlwaysOn
Переключение нескольких баз
(концепция Availability Groups)
Автоматическое переключение
Несколько копий базы
Чтение с копий
Перенаправление соединения
пользователя в случае отказа основной
базы
Оптимизированный алгоритм работы
Track # – Session #
14
AlwaysOn – Механизм работы
Commit
1
7
Подтверждение
Подтверждение
6
Запись данных
в базу
2
Запись в
локальный
Log
DB
Передача данных
2
3
Log
Сохранено в
локальном log
Запись в
log
4
5
Log
DB
Track # – Session #
15
AlwaysOn
A
A
A
A
Track # – Session #
16
Процесс
восстановления
после сбоя
Availability
Group Listener
AlwaysOn
Track # – Session #
17
SQL Server
Шардинг
v
Резервирование
Управление
• Рост и уменьшение объёма
данных (покупка/продажа
серверов)
• ПО, Обновление, Высокая
доступность
Шардинг
Маршрутизация
Управление секциями
• Где находятся мои данные?
• Разбиение и слияние
• Распределение данных
Track # – Session #
19
Способы шардинга данных
Диапазон – разбиение диапазона на секции
Диапазоны могут иметь разный размер
Хороший выбор для запросов по диапазону
Может не выдержать большой нагрузки
Хеширование – использование хэша в качестве ключа
Отличное решение для распределения данных
Плохое для запросов по диапазону
Необходимо точно оценивать требования к нагрузке
Track # – Session #
20
Управление схемой
Дизайн схемы должен исключать взаимодействие
между базами данных
Процесс обновление схемы должен быть устойчивым
Код приложения должен:
Поддерживать несколько схем при обновлении
Останавливать обработку запросов во время обновления
Track # – Session #
21
Распределённые запросы
Задумайтесь можно ли обойтись без них
Запускайте запросы к разным базам
параллельно и агрегируйте результаты
Используйте несколько соединений и
многопоточность для увеличения
производительности
Track # – Session #
22
SQL Server and SQL Azure shard library
Track # – Session #
23
SQL Azure
Шардинг
v
SQL Azure Federations
С точки зрения базы данных это
объект, который позволяет
масштабировать базу данных и
распределять её данные между
отдельными базами данных.
С точки зрения пользователя это
набор метаданных о том как
распределены данные между
базами данных и удобная модель
работы с этими данными
Track # – Session #
25
Концепция Fеderations
Federations
SalesDB
CustomerFederationeration
CustomerFederationeration
CustomerFederation
Federation Root
Federation Members
Federation Root
База данных в которой находится объект Federation
Federation
Federation – объект Root базы данных, который знает как распределены данные между шардами
Federation Member (aka Шард):
Отдельная база данных SQL Azure. Каждая такая база данных, хранит в себе часть общего набора
данных.
Track # – Session #
26
Концепция Fеderations
Federations
SalesDB
CustomerFederationeration
CustomerFederationeration
CustomerFederation
Federation Root
member: Range [1000, 2000)
AU
PK=5
AU
PK=5
AU
PK=25
AU
PK=1005
AU
PK=25
AU
PK=35
AU
PK=1025
AU
PK=35
AU
PK=1035
Atomic Units
Federation Distribution Key
Ключ, используемый для распределения данных внутри федерации. Он определяет тип
данных ключа (uniqueidentifier, int, bigint, varbinary), и способ распределения данных (range).
Его значение определяет Federation Member, на котором будут находиться данные.
Atomic Unit
Все данные имеющие одинаковый Federation Distribution Key. Например это все строки
федеративных таблиц, которые имеют один федеративный ключ. Эта коллекция данных
гарантированно будет находиться на одном и том-же шарде (federation member).
Track # – Session #
27
Концепция Fеderations
Central Tables
Federations
SalesDB
Federated Tables
CustomerFederationeration
CustomerFederationeration
CustomerFederation
Reference Tables
User Database and
Federation root
Federated Tables
Federation members
Содержат кусочек распределённых данные. Federated tables создаются в federation members и
содержат federation distribution key.
Reference Tables
Содержат данные необходимые для lookup запросов. Создаются в Federation Member. Данные таблиц
реплицируются между всеми Federation Members.
Central Table
Таблицы, созданные в federation root базе данных. Используются в основном как набор метаданных.
Track # – Session #
28
Маршрутизация
USE FEDERATION CustomerFederation(customer_id = 5075) …
SalesDB
CustomerFederationeration
CustomerFederationeration
CustomerFederation
Range Distribution [min,1000, 2000, 3000 …..
5000, 10000, Max]
Приложение всегда вначале соединяется с ROOT database
USE FEDERATION – переключает в контекст конкретного
federation member
Данные с одинаковым значением federation key (atomic unit)
всегда находятся в пределах одного federation member
Track # – Session #
29
Маршрутизация – Member Connection
USE FEDERATION CustomerFederation(cid = 55)
WITH RESET, FILTERING=OFF
GO
member: Range [100,200)
Products
(referece)
SalesDB
CustomerFederation
CustomerFederation
Customer_id=55
Customers
(federated)
Orders
(federated)
Microsoft Confidential
FILTERING=OFF
Работаем с данными всего Federation member
Неограниченный доступ к данным базы: Всё равно что соединиться по имени БД
DDL, DML и доступ ко всем Atomic Units внутри Federation Member
Хорошо для…
Management Tasks: Обновление схемы данных
Fan-out Querying – получение данных нескольких atomic units
Track # – Session #
30
Маршрутизация – Filtering connection
USE FEDERATION CustomerFederation(cid = 55)
WITH RESET, FILTERING=ON
GO
member: Range [100,200)
Products
(referece)
SalesDB
CustomerFederation
CustomerFederation
Customer_id=55
Customers
Orders
(federated)Customer_id=55(federated)
Microsoft Confidential
FILTERING=ON
Работаем с данными одного Atomic Unit
Полностью доступны данные Reference Tables
Запрещены любые изменения глобального состояния Federation Member
Хорошо для…
Безопасной модели разработки
Предотвращения утечки данных
Track # – Session #
31
Разделение шарда
ALTER FEDERATION CustomerFederation SPLIT AT (CustomerId=7500)
SalesDB
Orders_federation
CustomerFederationeration
CustomerFederation
Range Distribution [min,1000, 2000, 3000 …..
5000, 10000, Max]
Разделение шарда делается при помощи T-SQL
команды SPLIT.
Разделение шарда происходит без остановки
работы приложения. Данные шарда недоступны
в течении очень короткого промежутка времени.
Track # – Session #
32
Сценарий применения
Приложение, обрабатывающее заказы
множества покупателей и обслуживающее
большую базу продуктов.
Database Name = SalesDB
Federations = CustomerFederation (CustomerId int
RANGE)
Federation distribution key = CustomerId
Federated Tables = Customers, Orders
Reference Tables = Products
Track # – Session #
33
SQL Azure Federations
Демонстрация
v
БД размером 75 Тб
Track # – Session #
35
SQL Azure Federations vNext
Управление схемой данных
Поддержка управления схемами членов федерации. Больший контроль
процесса обновления схемы
Эмуляция Federations
Локальная эмуляция Federations, для того, чтобы разрабатывать
приложения под Federations, не используя SQL Azure
Автоматический шардинг
Автоматическое разбиение базы данных в зависимости от
определённого критерия (время отклика, размер базы данных и т.п.)
Распределённые запросы
Получение данных с нескольких Federation Members одним запросом
Track # – Session #
36
Масштабирование
Масштабирование в SQL Azure – Шардинг
http://reznik.uneta.com.ua/post/2011/05/16/sql-azure-federations-sharding-in-sql-azure.aspx
Знакомимся с SQL Azure Federations
http://reznik.uneta.com.ua/post/2011/05/25/introducing-to-sql-azure-federations.aspx
SQL Azure - Your Data in the Cloud (Cihan Biyikoglu)
http://blogs.msdn.com/b/cbiyikoglu/
Video: Building Scale-Out Database Solutions on SQL Azure
http://player.microsoftpdc.com/Session/591d586f-3732-4bff-8ee2-857f27d74df4
Windows Azure Platform Training Kit - October Update
http://www.microsoft.com/download/en/details.aspx?id=8396
Multi-tenant SQL Azure Federations Sample
http://shard.codeplex.com/
SQL Azure Federation Data Migration Wizard
http://sqlazurefedmw.codeplex.com/
SQL Server and SQL Azure Shard Library
http://enzosqlshard.codeplex.com/
Track # – Session #
37
Масштабирование
Способность справляться с увеличением
нагрузки без влияния на производительность
Высокая доступность и отказоустойчивость
Управляемость и сопровождаемость
Track # – Session #
38
Спасибо!
v