Scaling out with Azure SQL Database (Horizontális felskálázás az Azure SQL Database segítségével)Scaling out with Azure SQL Database

Azure SQL Database-adatbázisok könnyen lehet horizontálisan a Elastic Database eszközök.You can easily scale out Azure SQL databases using the Elastic Database tools. Az eszközök és a szolgáltatások lehetővé teszik, hogy az adatbázis-erőforrások használata Azure SQL Database megoldások tranzakciós munkaterhelések, és különösen a szoftver egy szolgáltatott szoftverként (SaaS) alkalmazásokként létrehozásához.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. A rugalmas adatbázis-szolgáltatások álló a:Elastic Database features are composed of the:

A következő ábrán látható egy architektúra, amely tartalmazza a rugalmas adatbázis-szolgáltatások viszonyítva adatbázisok gyűjteménye.The following graphic shows an architecture that includes the Elastic Database features in relation to a collection of databases.

A kép színeit az adatbázis sémák határoz meg.In this graphic, colors of the database represent schemas. Ugyanazzal a színnel adatbázisok ugyanazon séma megosztani.Databases with the same color share the same schema.

  1. Egy Azure SQL-adatbázisok Azure-ban horizontális architektúrát működtetnek.A set of Azure SQL databases are hosted on Azure using sharding architecture.
  2. A Elastic Database ügyféloldali kódtárának shard kezelésére szolgál.The Elastic Database client library is used to manage a shard set.
  3. Az adatbázisok egy részhalmazát engedélyeznie kell egy rugalmas készlet.A subset of the databases are put into an elastic pool. (Lásd: Mi az, hogy a tárolókészlet?).(See What is a pool?).
  4. Egy rugalmas feladat ütemezett vagy alkalmi T-SQL parancsfájlt futtat minden adatbázisokhoz.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. A vegyes egyesítéses eszköz adatok áthelyezése egy shard másik szolgál.The split-merge tool is used to move data from one shard to another.
  6. A rugalmas adatbázis-lekérdezés lehetővé teszi, hogy az összes adatbázis shard készletében is.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. Rugalmas tranzakciók teszik tranzakciók, amelyek több több adatbázis futtatását.Elastic transactions allow you to run transactions that span several databases.

Rugalmasadatbázis-eszközök

Az eszközök miért érdemes használni?Why use the tools?

Egyszerű, a virtuális gépek és a blob-tároló elérése érdekében a rugalmasság és a felhőalapú alkalmazások számára is méretezhető lett - egyszerűen hozzáadása vagy kivonás egységek, vagy növelje a power.Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. Azonban ez az állapot-nyilvántartó adatok feldolgozása a relációs adatbázisok kihívást maradt.But it has remained a challenge for stateful data processing in relational databases. Kihívást kiderült, a következő használati helyzetekben:Challenges emerged in these scenarios:

  • A számítási feladatok relációs adatbázis része kapacitása zsugorítását, és inkább.Growing and shrinking capacity for the relational database part of your workload.
  • Az adatok – például egy foglalt end-ügyfél (bérlő) egy adott részének érintő esetleg felmerülő elérési pontokhoz való kezelése.Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

Hagyományosan helyzetekben, például ezek eddig a nagyobb méretű adatbázis-kiszolgálók támogatásához az alkalmazás által az említett.Traditionally, scenarios like these have been addressed by investing in larger-scale database servers to support the application. Azonban ez a beállítás korlátozza a felhőben, ahol minden feldolgozás történik, az előre definiált hagyományos hardvereken.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. Ehelyett terjesztésére adatokat, és több azonos strukturált adatbázis közötti feldolgozása (a kibővített minta "horizontális" néven ismert) köszönhetően a hagyományos méretezett megközelítések költség-és a rugalmasság.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.

Vízszintes és függőleges skálázásHorizontal and vertical scaling

Az alábbi ábrán a vízszintes és függőleges dimenziók a méretezés, amely az alapvető módon, a rugalmas adatbázisok is méretezhető.The following figure shows the horizontal and vertical dimensions of scaling, which are the basic ways the elastic databases can be scaled.

Vízszintes és függőleges kibővítési

Horizontális skálázás hivatkozik hozzáadásával vagy eltávolításával adatbázisok ahhoz, hogy módosítsa a kapacitás vagy általános teljesítményét.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance. Ez is feltüntettük "skálázás".This is also called “scaling out”. Horizontális, amelyben adatok particionálása keresztül azonos strukturált adatbázisok gyűjteménye közös módja a horizontális skálázás végrehajtásához.Sharding, in which data is partitioned across a collection of identically structured databases, is a common way to implement horizontal scaling.

Függőleges skálázás bővítése vagy csökkentése az egyes adatbázisok teljesítményszintjét hivatkozik – ezt is nevezik "vertikális felskálázásával."Vertical scaling refers to increasing or decreasing the performance level of an individual database—this is also known as “scaling up.”

A legtöbb felhőméretű adatbázis-alkalmazások ezen két stratégiák együtt használja.Most cloud-scale database applications use a combination of these two strategies. Például a szoftver a szolgáltatásalkalmazás előfordulhat, hogy segítségével a függőleges skálázás és horizontális skálázás új végfelhasználóhoz kiépítéséhez minden end felhasználói adatbázis növekedhet és csökkenhet az erőforrásokat, a munkaterhelés szerint igény szerint.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.

  • Horizontális skálázás kezeli a Elastic Database ügyféloldali kódtárának.Horizontal scaling is managed using the Elastic Database client library.
  • Függőleges skálázás úgy hajthatja végre, Azure PowerShell-parancsmagok használatával módosíthatja a szolgáltatásszintet, vagy úgy, hogy adatbázisok rugalmas készlethez.Vertical scaling is accomplished using Azure PowerShell cmdlets to change the service tier, or by placing databases in an elastic pool.

HorizontálisSharding

Horizontális technika, nagy mennyiségű azonos strukturált adatok szét egy független adatbázisok számát.Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. Általában különösen szoftver létrehozása a végfelhasználók vagy a vállalatok számára a szolgáltatás (SAAS) ajánlatok felhő fejlesztőkkel.It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. Ezen end ügyfelek gyakran "bérlő" nevezik.These end customers are often referred to as “tenants”. Horizontális szükséges bármely számos oka lehet:Sharding may be required for any number of reasons:

  • Adatok teljes mérete túl nagy belül egy önálló adatbázisThe total amount of data is too large to fit within the constraints of a single database
  • A tranzakció átviteli képessége – a teljes munkaterhelés meghaladja az egy önálló adatbázis képességeitThe transaction throughput of the overall workload exceeds the capabilities of a single database
  • Bérlők szükség lehet egymástól, fizikai elkülönítése, így külön adatbázisok van szükség az egyes bérlők számáraTenants may require physical isolation from each other, so separate databases are needed for each tenant
  • Adatbázis különböző szakaszaiban kell lennie, a megfelelőségi, a teljesítmény vagy a geopolitikai okok különböző földrajzi területeken.Different sections of a database may need to reside in different geographies for compliance, performance, or geopolitical reasons.

Más esetekben, például az adatfeldolgozást az elosztott eszközökről származó adatok horizontális segítségével töltse ki a adatbázisok készleteit tartalmazó ideiglenesen vannak rendezve.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. Például egy másik adatbázist is számára dedikált, minden nap vagy hét.For example, a separate database can be dedicated to each day or week. Ebben az esetben a horizontális kulcs (a szilánkos tábla összes sora szerepel) dátumot jelölő egész szám lehet, és az alkalmazást a szóban forgó tartományát adatbázisok részhalmaz kell továbbítani, lekérdezések dátumtartomány adatainak lekérése során.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ális működik optimálisan, ha az alkalmazás minden tranzakció korlátozható egy horizontális skálázási kulcs egyetlen értéket.Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. Amely biztosítja, hogy minden tranzakció helyi adott adatbázishoz.That ensures that all transactions are local to a specific database.

Több-bérlős és a bérlői egyetlenMulti-tenant and single-tenant

Egyes alkalmazások használata a legegyszerűbb módszere az önálló adatbázist hoz létre az egyes bérlők számára.Some applications use the simplest approach of creating a separate database for each tenant. Ez a egybérlős horizontális mintát elkülönítési, biztonsági mentés/visszaállítás lehetősége és a bérlő részletességű skálázás erőforrás biztosít.This is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. Egyetlen bérlői horizontális az egyes adatbázisok vagy társítva egy adott bérlő azonosító értékét (felhasználói kulcs értékét), de kulcs nem minden esetben kell az adatokat mozgatná szerepel.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. Az alkalmazás felelőssége, hogy egyes kérelmek átirányítása a megfelelő adatbázis - és az ügyféloldali kódtár egyszerűbbé teheti a.It is the application’s responsibility to route each request to the appropriate database - and the client library can simplify this.

Több-bérlős és egybérlős

Más forgatókönyvek csomag több bérlő együtt az adatbázisok, nem pedig az önálló adatbázisok elszigetelése őket.Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. Ez az egy tipikus több-bérlős horizontális mintát - és azt a tényt, hogy egy alkalmazás kezeli-e nagy mennyiségű kis bérlők vezethetik.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. A több-bérlős horizontális a sorokat a táblák összes tervezték, hogy a kulcs, amely azonosítja a bérlő azonosítója vagy horizontális kulcs.In multi-tenant sharding, the rows in the database tables are all designed to carry a key identifying the tenant ID or sharding key. Ebben az esetben az alkalmazás réteg felelős a bérlőkérést útválasztási a megfelelő adatbázishoz, és ez a rugalmas adatbázis ügyféloldali kódtár támogatja.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. Emellett a sorszintű biztonság használható-e a szűrő mely sorai, minden bérlői hozzáférhessenek - további információkért lásd: több-bérlős alkalmazásokhoz a rugalmas adatbáziseszközöket és sorszintű biztonság.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. Adatbázisok között terjesztése lehet szükség a több-bérlős horizontális mintával, és ez megkönnyíti a rugalmas adatbázis vegyes egyesítéses eszköz.Redistributing data among databases may be needed with the multi-tenant sharding pattern, and this is facilitated by the elastic database split-merge tool. A rugalmas készleteket használó SaaS-alkalmazások szerkezeti kialakításainak alaposabb megismeréséhez olvassa el a Tervminták több-bérlős SaaS-alkalmazásokhoz Azure SQL Database esetén című részt.To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.

Adatok áthelyezése több single-bérlőhöz adatbázisokhozMove data from multiple to single-tenancy databases

Egy SaaS-alkalmazás létrehozása, esetén jellemző, a lehetséges ügyfelek felajánlott a szoftver próbaverzióját.When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. Ebben az esetben is költséghatékony, hogy egy több-bérlős adatbázisban az adatok.In this case, it is cost-effective to use a multi-tenant database for the data. Azonban az ügyfél egy potenciális válásakor single-bérlő adatbázis jobb, mivel jobb teljesítményt nyújt.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. Ha a felhasználói adatok hozna létre, a próbaidőszak során, használja a vegyes egyesítéses eszköz a több-bérlős az adatok áthelyezése az új single-bérlő adatbázis.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.

Következő lépésekNext steps

Azt mutatja be, az ügyféloldali kódtár mintaalkalmazást, lásd: Ismerkedés a rugalmas adatbáziseszközöket.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

További információ meglévő adatbázisok használata az eszközök átalakításáról: telepítse át a meglévő adatbázisok horizontális.To convert existing databases to use the tools, see Migrate existing databases to scale out.

A rugalmas készlet mintaadatokról, olvassa el rugalmas készletek ára és teljesítménye szempontok, vagy hozzon létre egy új készletet a rugalmas készletek.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.

További forrásokAdditional resources

Rugalmas adatbáziseszközöket még nem használ?Not using elastic database tools yet? Tekintse meg a Getting Started Guide.Check out our Getting Started Guide. A kérdésekhez, lépjen kapcsolatba velünk a a SQL-adatbázis fórum és a szolgáltatás kéréseket, adja hozzá őket a SQL adatbázis-visszajelzési fórumon.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.