Horizontální navýšení kapacity s Azure SQL DatabaseScaling out with Azure SQL Database

Můžete snadno škálovat databáze Azure SQL pomocí elastické databáze nástroje.You can easily scale out Azure SQL databases using the Elastic Database tools. Tyto nástroje a funkce, budete moct použít databázi prostředků Azure SQL Database vytvářet řešení pro transakční zatížení a hlavně Software jako služba (SaaS) aplikace.These tools and features let you use the database resources of Azure SQL Database to create solutions for transactional workloads, and especially Software as a Service (SaaS) applications. Funkce elastické databáze se skládají z:Elastic Database features are composed of the:

Následující obrázek znázorňuje architekturu, která zahrnuje elastické databáze funkce ve vztahu k kolekce databáze.The following graphic shows an architecture that includes the Elastic Database features in relation to a collection of databases.

V této grafiky představují barvy databáze schémat.In this graphic, colors of the database represent schemas. Databáze s stejné barvy sdílet stejné schéma.Databases with the same color share the same schema.

  1. Sadu databází Azure SQL jsou hostované v Azure pomocí architektury horizontálního dělení.A set of Azure SQL databases are hosted on Azure using sharding architecture.
  2. Klientské knihovny pro elastické databáze slouží ke správě sadu horizontálního oddílu.The Elastic Database client library is used to manage a shard set.
  3. Podmnožinu databází jsou vloženy do elastický fond.A subset of the databases are put into an elastic pool. (Viz co je fond?).(See What is a pool?).
  4. Úlohy elastické databáze spustí naplánované nebo ad hoc skriptů T-SQL pro všechny databáze.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. Nástroji pro sloučení rozdělení se používá pro přesun dat z jedné horizontálního oddílu do jiného.The split-merge tool is used to move data from one shard to another.
  6. Elastické databáze dotazu umožňuje vytvořit dotaz, který zahrnuje všechny databáze v sadě horizontálního oddílu.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. Elastické transakce vám umožní spustit transakce, které jsou rozmístěny v několika databází.Elastic transactions allow you to run transactions that span several databases.

Nástroje pro elastické databáze

Proč používat nástroje?Why use the tools?

Dosažení pružnost a škálování pro cloudové aplikace byla přehledné pro virtuální počítače a úložiště objektů blob – jednoduše přidat odečtena jednotek nebo zvýšení výkonu.Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. Ale zůstal výzvu pro zpracování stavových dat v relačních databází.But it has remained a challenge for stateful data processing in relational databases. Výzvy vyplývá v těchto scénářích:Challenges emerged in these scenarios:

  • Zvětšování a zmenšování kapacity pro relační databázi část vašich úloh.Growing and shrinking capacity for the relational database part of your workload.
  • Správa aktivní body, které může způsobit, které mají vliv na určitou podmnožinu dat – například zaneprázdněn end zákazníků (klientů).Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

Obvyklým scénáře takovéto mít vyřeší investicemi v serverech databáze větší škálování k podpoře aplikace.Traditionally, scenarios like these have been addressed by investing in larger-scale database servers to support the application. Tato možnost je však omezená v cloudu, kde se stane veškeré zpracování na předdefinované komoditním hardwaru.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. Místo toho distribuci dat a zpracování mezi mnoha databázemi stejně jako strukturovaný (známé jako "horizontálního dělení" vzor Škálováním na více systémů) představuje alternativu ke tradiční přístupy škálování z hlediska nákladů a pružnost.Instead, distributing data and processing across many identically structured databases (a scale-out pattern known as "sharding") provides an alternative to traditional scale-up approaches both in terms of cost and elasticity.

Vodorovného a svislého škálováníHorizontal and vertical scaling

Následující obrázek znázorňuje vodorovného a svislého rozměry škálování, které jsou základní způsoby, které je možné rozšířit elastické databáze.The following figure shows the horizontal and vertical dimensions of scaling, which are the basic ways the elastic databases can be scaled.

Vodorovný versus svislé škálování

Vodorovné škálování odkazuje na přidáním nebo odebráním databází, aby bylo možné upravit kapacity nebo celkový výkon.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance. To je také označován "škálování" out.This is also called “scaling out”. Horizontálního dělení, ve kterém jsou data rozdělena v kolekci stejně jako strukturovaný databází, je běžné způsob, jak implementovat vodorovné škálování.Sharding, in which data is partitioned across a collection of identically structured databases, is a common way to implement horizontal scaling.

Svislé škálování odkazuje zvýšením nebo snížením úrovně výkonu jednotlivé databáze – to se také označuje jako "vertikálním navýšení kapacity."Vertical scaling refers to increasing or decreasing the performance level of an individual database—this is also known as “scaling up.”

Většina databázových aplikací cloudového škálovatelného použít kombinaci těchto dvou strategií.Most cloud-scale database applications use a combination of these two strategies. Software jako služba aplikace může například použít vodorovné škálování zřídit nové koncové zákazníky a svislé škálování aby zvětšovat a zmenšovat prostředky podle potřeby úlohy databázi každého koncoví zákazníka.For example, a Software as a Service application may use horizontal scaling to provision new end-customers and vertical scaling to allow each end-customer’s database to grow or shrink resources as needed by the workload.

  • Vodorovné škálování je spravovat pomocí klientské knihovny pro elastické databáze.Horizontal scaling is managed using the Elastic Database client library.
  • Svislé škálování se provádí pomocí rutin prostředí Azure PowerShell Pokud chcete změnit úroveň služby, nebo umístění databází v elastickém fondu.Vertical scaling is accomplished using Azure PowerShell cmdlets to change the service tier, or by placing databases in an elastic pool.

Horizontálního děleníSharding

Horizontálního dělení jde o techniku distribuovat velkých objemů stejně jako strukturovaná data mezi několik nezávislých databáze.Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. Jde zejména oblíbených s vývojáři cloudu vytváření Software jako služba (SAAS) nabídky pro koncové zákazníky nebo firmy.It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. Tyto koncové zákazníky se často označuje jako "klienty".These end customers are often referred to as “tenants”. Horizontálního dělení může být nutný pro libovolný počet důvodů:Sharding may be required for any number of reasons:

  • Celkové množství dat je příliš velký, aby vyhovovaly limitu omezení služby jedné databázeThe total amount of data is too large to fit within the constraints of a single database
  • Transakce propustnost celkové zatížení přesáhne možnosti služby jedné databázeThe transaction throughput of the overall workload exceeds the capabilities of a single database
  • Klienti mohou vyžadovat fyzické izolace od sebe navzájem tak samostatné databáze jsou potřeba pro každého klientaTenants may require physical isolation from each other, so separate databases are needed for each tenant
  • Různé části databáze potřebovat jsou umístěny v různých zeměpisných regionech pro dodržování předpisů, výkon nebo geopolitické důvodů.Different sections of a database may need to reside in different geographies for compliance, performance, or geopolitical reasons.

V dalších scénářích, třeba přijímání dat z distribuované zařízení může být horizontálního dělení použitou k vyplnění sadu databází, která jsou uspořádána dočasně.In other scenarios, such as ingestion of data from distributed devices, sharding can be used to fill a set of databases that are organized temporally. Například samostatné databáze může být vyhrazený pro každého dne nebo týdne.For example, a separate database can be dedicated to each day or week. V takovém případě klíč horizontálního dělení může být celé číslo představující datum (součástí všechny řádky horizontálně dělené tabulky) a aplikací na podmnožinu databází vztahující se konkrétní oblast musejí směrovat dotazy načítají se informace o pro konkrétní období.In that case, the sharding key can be an integer representing the date (present in all rows of the sharded tables) and queries retrieving information for a date range must be routed by the application to the subset of databases covering the range in question.

Horizontálního dělení je nejvhodnější při každé transakci v aplikaci může být omezen na jednu hodnotu klíče horizontálního dělení.Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. Která zajistí, že všechny transakce jsou místní pro konkrétní databázi.That ensures that all transactions are local to a specific database.

Více klientů a jednoho klientaMulti-tenant and single-tenant

Některé aplikace použít nejjednodušší způsob vytváření samostatnou databázi pro každého klienta.Some applications use the simplest approach of creating a separate database for each tenant. Toto je jednoho klienta horizontálního dělení vzor izolace, možnost zálohování a obnovení a prostředků, škálování na členitost klienta, který poskytuje.This is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. S horizontálního dělení jednoho klienta je přidružená hodnota ID konkrétní klienta (nebo hodnota klíče zákazníka) každou databázi, ale klíči nemusí být vždy přítomen v samotná data.With single tenant sharding, each database is associated with a specific tenant ID value (or customer key value), but that key need not always be present in the data itself. Je zodpovědností aplikace směrovat každý požadavek na příslušnou databázi - a klientské knihovny můžete zjednodušit tím.It is the application’s responsibility to route each request to the appropriate database - and the client library can simplify this.

Jednoho klienta a více klientů

Jiné scénáře pack víc klientů současně do databáze, místo izoluje je do samostatné databáze.Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. Toto je typické horizontálního dělení víceklientské vzor - a mohou být řízeny fakt, že aplikaci spravuje velké množství malých klientů.This is a typical multi-tenant sharding pattern - and it may be driven by the fact that an application manages large numbers of small tenants. V víceklientské horizontálního dělení jsou všechny řádků v tabulkách databáze navrženy pro provádění klíč, který identifikuje ID klienta nebo klíč horizontálního dělení.In multi-tenant sharding, the rows in the database tables are all designed to carry a key identifying the tenant ID or sharding key. Znovu aplikační vrstvě je zodpovědná za směrování požadavek klienta na příslušnou databázi, a to může podporovat klientské knihovny pro elastické databáze.Again, the application tier is responsible for routing a tenant’s request to the appropriate database, and this can be supported by the elastic database client library. Kromě toho zabezpečení na úrovni řádků slouží k filtru řádky k přístup každý klient – podrobnosti najdete v tématu víceklientským aplikacím s nástroje elastické databáze a zabezpečení na úrovni řádků.In addition, row-level security can be used to filter which rows each tenant can access - for details, see Multi-tenant applications with elastic database tools and row-level security. Redistribuce data mezi databáze může být potřeba pomocí vzoru horizontálního dělení více klientů, a to usnadňují nástrojem rozdělení sloučení elastické databáze.Redistributing data among databases may be needed with the multi-tenant sharding pattern, and this is facilitated by the elastic database split-merge tool. Další informace o návrhových schématech aplikací SaaS využívajících elastické fondy najdete v tématu Návrhová schémata pro víceklientské aplikace SaaS využívající službu Azure SQL Database.To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.

Přesun dat z více k databázím jedním klientůMove data from multiple to single-tenancy databases

Při vytváření aplikace SaaS, je obvykle nabízejí potenciální zákazníci zkušební verzi softwaru.When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. V takovém případě je nákladově efektivní používání víceklientské databáze pro data.In this case, it is cost-effective to use a multi-tenant database for the data. Když se stane potenciálního zákazníka zákazníka, databázi jednoho klienta je nicméně lepší vzhledem k tomu, že poskytuje lepší výkon.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. Pokud zákazník vytvořili dat během zkušební doby, použijte nástroji pro sloučení rozdělení pro přesun dat z více klientů k nové databázi jednoho klienta.If the customer had created data during the trial period, use the split-merge tool to move the data from the multi-tenant to the new single-tenant database.

Další krokyNext steps

Ukázkovou aplikaci, která demonstruje klientské knihovny, najdete v části začít pracovat s nástroji elastické databáze.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

Chcete-li převést existující databáze používat nástroje, přečtěte si téma migrovat existující databáze pro rozšíření Škálováním.To convert existing databases to use the tools, see Migrate existing databases to scale out.

Specifika elastického fondu, najdete v sekci cenové a výkonové požadavky fondu elastické databáze, nebo vytvořit nový fond s elastické fondy.To see the specifics of the elastic pool, see Price and performance considerations for an elastic pool, or create a new pool with elastic pools.

Další zdrojeAdditional resources

Není ještě pomocí nástroje elastické databáze?Not using elastic database tools yet? Podívejte se na naše – Příručka Začínáme.Check out our Getting Started Guide. Máte dotazy, kontaktujte nás na fórum SQL Database a pro žádosti o funkce, přidejte je do fóru pro zpětnou vazbu SQL Database.For questions, please reach out to us on the SQL Database forum and for feature requests, please add them to the SQL Database feedback forum.