Одна из вещей, которая будет представлена в следующем обновлении SQL Azure, — это решение для разделения базы данных под названием SQL Azure Federations. У Брайана и меня будет несколько примеров использования этой функции с конкретными языками после ее выпуска, но мы подумали, что было бы неплохо иметь вступительную статью, чтобы немного объяснить эту функцию и что она означает для разработчиков OSS.
Итак, сначала подведем итоги всей этой статьи, заявив, что федерации в SQL Azure должны работать с любым языком или технологией OSS, которые могут взаимодействовать с SQL Azure. Федерации будут реализованы с использованием SQL Azure Transact-SQL, поэтому почти все должно работать с федеративными данными. Продолжайте читать для деталей и ссылок на связанную информацию.
Что такое шардинг и почему он полезен?
Типичная база данных содержит одну или несколько таблиц, которые в свою очередь содержат строки, состоящие из столбцов. Так что же происходит, когда у вас так много данных, что база данных выросла до огромного размера, вам не хватает места на диске, ваш сервер не может обработать все входящие соединения, или ваш индекс огромен, и это влияет на ваш производительность запроса? Часто вы переходите к разделению данных на несколько баз данных. Вместо одной гигантской базы данных у вас теперь есть куча меньших. В большинстве случаев вы не будете хранить эти небольшие базы данных вместе на одном сервере, а вместо этого разделите их на несколько серверов. Это позволяет распределить нагрузку обработки на несколько машин и масштабировать вместо увеличения.
Существует два способа разделения баз данных: по горизонтали и по вертикали. Просто подумайте о строках и столбцах в вашей базе данных как о сетке; горизонтальное разбиение разделяет строки, в то время как вертикальное разбиение разделяет столбцы. Осколок — это форма горизонтального разделения; разбивая ваши данные на уровне строк. В итоге вы получите кучу баз данных (осколков), каждая из которых содержит кусочек таблицы. Таким образом, при использовании шардинга вы получите несколько баз данных (шардов), каждая из которых содержит одну и ту же таблицу (скажем, таблицу клиентов), но каждая база данных (шард) содержит только определенное подмножество общих строк в таблице.
Разделение может быть немного сложным для реализации, поскольку вам нужно найти способ разделения строк между базами данных, который обеспечивает хорошее использование всех баз данных и сохраняет все данные, к которым вы обычно запрашиваете, вместе. Например, если у вас есть таблица клиентов и таблица заказов, вы можете использовать значение customerID для разделения строк. Строки в обеих таблицах, которые содержат значения 0-100, попадают в базу данных A, значения 101-200 — в базу данных B, 201-300 — в базу данных C и т. Д. Здесь нужно следить за тем, как вы назначаете значение customerID; если вы последовательно назначаете его клиентам, база данных A заполнится до того, как B и C будут когда-либо использованы. В идеале вы хотели бы назначить значение случайным образом, чтобы новые клиенты распределялись по базам данных.
Другая проблема с разделением — это то, что вашему приложению часто требуется понимание баз данных (сегментов), участвующих в решении, чтобы он знал, поступает ли запрос для customerID 167, что ему необходимо подключиться к databaseB для получения этой информации.
SQL Azure Федерации
SQL Azure Federations — это решение для разделения, встроенное в SQL Azure. Одной из особенностей федераций является то, что вы можете взять осколок и разбить его на лету без каких-либо простоев. Таким образом, вы можете создать федерацию, которая начинается с одного сегмента, охватывающего все потенциальные диапазоны (например, 0-900). Если она начинает приближаться к максимальному размеру базы данных или если ваша производительность уменьшается из-за большого размера индекса и т. Д., Вы можете выполнить команду, которая разбивает начальный осколок на два осколка, каждый из которых теперь покрывает часть потенциальных диапазонов для этой федерации. Например, один теперь может охватывать диапазон 0-500, а другой — 501-900.
Федерации не решают первую проблему шардинга, о которой я упоминал выше, вам все равно нужно придумать значение, которое будет использоваться для определения того, как вы разбиваете строки на сегменты, и убедитесь, что оно позволяет вам в равной степени использовать шарды, но оно разрешает проблема с необходимостью знать, к какой базе данных подключаться.
Утверждения T-SQL федерации
Остановимся на них сейчас, поскольку полная ссылка на них должна быть доступна, как только эта функция будет запущена. Но на основании прошлых сообщений в блоге из группы продуктов SQL Azure и некоторых опубликованных лабораторных работ можно ожидать следующее:
СОЗДАТЬ ФЕДЕРАЦИЮ
Этот оператор используется для создания новой федерации. Вот пример:
CREATE FEDERATION Orders_Federation (CustID INT RANGE) This would create a new federation named ‘Orders_Federation’. The ‘CustID INT RANGE’ is the federation distribution key, and specifies how data within this federation will be sharded; by range, using an integer value.
This statement will mark the database you run it in as the federation root database. The federation root database is used when performing some management tasks, and it is also responsible for routing connections to member databases. This command will also create the initial federation member (shard) for this federation. This initial member will cover all values from the min value to max value covered by the distribution type you specified.
Federation members are physically implemented as SQL Azure databases, and can be hosted on separate nodes within the Windows Azure data center. SQL Azure also automatically keeps three copies of them for disaster recovery purposes, just like all other databases in SQL Azure.
USE FEDERATION
This statement is used to connect to a federation. This is where some of the federation magic happens; when connecting to a federation, your application doesn’t need to know anything about the underlying physical federation members, just the federation distribution key. The USE statement will connect to the federation root database, which will then route the connection to the federation member database that contains the rows matching the distribution value you specify. Here’s an example:
USE FEDERATION Orders_Federation (CustID = '100') WITH RESET, FILTERING = OFF
This statement will connect to the Orders_Federation root database, figure out what federation member (shard) contains the value of ‘100’ for the CustID distribution key, and route the connection to that database. FILTERING = OFF instructs the connection to make the entirety of the member database available on this connection. If FILTERING is set to ON, only rows containing the value of ‘100’ will be returned.
You can also connect directly to the federation root by specifying USE FEDERATION ROOT.
CREATE TABLE…FEDERATED ON
This statement is used to create federated tables; tables that will have their data partitioned across the federation members (shards). Here’s an example:
: CREATE TABLE Customers( CustomerID int NOT NULL, CompanyName nvarchar(50) NOT NULL, FirstName nvarchar(50), LastName nvarchar(50), PRIMARY KEY (CustomerId) ) FEDERATED ON (CustID = CustomerID)
Note the FEDERATED ON clause. This associates the CustomerID field of this table with the CustID distribution key for this federation. This is how the federation knows how to split the rows of this table across the federation members (shards). After running this command, the Customers table will exist in every federation member, each of which will cover a subset of the table rows based on the value of the CustomerID field.
You can also create reference tables (tables created without the FEDERATE ON clause,) within a federation member. Generally reference tables hold static information that needs to be used in your queries, such as looking up what state based on a zip code. Since SQL Azure doesn’t support joins across databases, you’d want this reference information to be replicated in each federation member.
ALTER FEDERATION
This is another bit of federation magic; you can alter the federation layout on the fly without incurring any downtime. This includes SPLIT operations that take one of your existing federation members (shards) and splits it into two new members. Here’s an example:
ALTER FEDERATION Orders_Federation SPLIT AT (CustID = '100') This would find the federation member that contains the value ‘100’ for the CustID distribution key, and split it into two new federation members at that value. If this was performed against a federation that contained a single federation member (covering min value to max value for the INT type,) then after the operation the federation would contain two federation members; one containing distribution values from min value to 100 and another containing distribution values from 101 to max.
While this operation is going on, all data contained in the member being split is still available. You’re application has no clue that a split operation is going on (unless it initiated the operation or peeks at metadata about databases,) and queries should operate as normal. Once the operation is complete, rows for federated tables originally contained within the source federation member will now be contained with the two new members.
ALTER FEDERATION also supports DROP, which drops an existing federation member (shard). All data contained in the shard is dropped also, but the distribution range covered by the dropped database will now be covered by an adjacent member database.
There won’t be support for a MERGE operation in this release of federations, however it will be implemented at some point in the future: http://blogs.msdn.com/b/cbiyikoglu/archive/2011/07/11/shipping-fast-sharding-to-federations-in-from-pdc-2010-to-2011.aspx
No matter how many SPLIT or DROP operations you perform on a federation, the federation members will cover the entire range of values specified by the federation distribution key. In this case, the range of values for an INT.
Summary
SQL Azure federations is an upcoming feature of SQL Azure that allows you to dynamically scale your data, and since it’s implemented as SQL Azure Transact-SQL statements, any OSS technology that can talk to SQL Azure can use it.
References
Here’s some reference material that I used while creating this article:
- SQl Azure Federations Hands On Labs – http://msdn.microsoft.com/en-us/hh532130. Use this to get up to speed once federations release.
- Cihan Biyikoglu’s blog posts on SQL Azure Federations – http://blogs.msdn.com/b/cbiyikoglu/archive/tags/federations/. Pretty much everything you ever wanted to know about federations.