Az SQL-adattárház méretezési, skálázási és sorkezelési viselkedése

Ez a cikk az SQL-tárolók fürtméretezését, sorba állítását és automatikus skálázási viselkedését ismerteti.

Kiszolgáló nélküli SQL Warehouse méretezése

A kiszolgáló nélküli SQL Warehouse-hoz mindig nagyobb pólómérettel kell kezdenie, mint gondolná, és a tesztelés során le kell méreteznie. Ne kezdjen egy kis pólómérettel a kiszolgáló nélküli SQL Warehouse-hoz, és lépjen fel. Általánosságban elmondható, hogy egyetlen kiszolgáló nélküli SQL-raktárral kell kezdenie, és az Azure Databricksre támaszkodva a kiszolgáló nélküli fürtökkel a megfelelő méretre, a számítási feladatok rangsorolására és a gyors adatolvasásra támaszkodhat. Lásd: Kiszolgáló nélküli automatikus skálázás és lekérdezéssor-kezelés.

• Egy adott kiszolgáló nélküli SQL-raktár lekérdezési késésének csökkentése:
  • Ha a lekérdezések a lemezre kerülnek, növelje a póló méretét.
  • Ha a lekérdezések rendkívül párhuzamosak, növelje a póló méretét.
  • Ha egyszerre több lekérdezést futtat, adjon hozzá további fürtöket az automatikus skálázáshoz.
• A költségek csökkentése érdekében próbálja meg a pólóméretet csökkenteni anélkül, hogy a lemezre ömlik, vagy jelentősen növelené a késést.
• A kiszolgáló nélküli SQL Warehouse megfelelő méretének érdekében használja az alábbi eszközöket:
  • Monitorozási oldal: tekintse meg a lekérdezések maximális számát. Ha a várólistára helyezett csúcs gyakran egy fölött van, vegyen fel fürtöket. Egy üzenetsor lekérdezéseinek maximális száma az SQL Warehouse-típusok esetében 1000. Lásd: SQL-raktár figyelése.
  • Lekérdezési előzmények. Lásd a lekérdezési előzményeket.
  • Lekérdezési profilok (keresse meg az 1 feletti lemezre kiömlött bájtokat). Lásd: Lekérdezési profil.

Feljegyzés

A kiszolgáló nélküli SQL-tárolók esetében a fürtméretek bizonyos esetekben eltérő példánytípusokat használhatnak, mint a pro és a klasszikus SQL-raktárak dokumentációjában felsoroltaktól a megfelelő fürtmérethez. A kiszolgáló nélküli SQL-raktárak fürtméreteinek ár/teljesítmény aránya általában hasonló a pro és a klasszikus SQL-raktárakéhoz.

Kiszolgáló nélküli automatikus skálázás és lekérdezéssor-kezelés

Az intelligens számítási feladatok kezelése (IWM) olyan funkciók készlete, amelyek növelik a kiszolgáló nélküli SQL-tárolók azon képességét, hogy nagy mennyiségű lekérdezést gyorsan és költséghatékonyan dolgozzanak fel. Az AI-alapú előrejelzési képességek használatával elemezheti a bejövő lekérdezéseket, és meghatározhatja a leggyorsabb és hatékonyabb (prediktív IO) IWM-et, hogy a számítási feladatok gyorsan megfelelő mennyiségű erőforrással rendelkezzenek. A legfontosabb különbség a Databricks SQL AI-képességeiben rejlik, hogy statikus küszöbértékek használata helyett dinamikusan reagáljon a számítási feladatok igényeire.

Ez a válaszkészség a következőket biztosítja:

• Gyors felskálázás, hogy szükség esetén több számítást szerezzen be az alacsony késés fenntartásához.
• A lekérdezések beengedése közelebb áll a hardver korlátozásához.
• Gyors leskálázás a költségek minimalizálása érdekében, ha alacsony a kereslet, és egységes teljesítményt biztosít az optimalizált költségekkel és erőforrásokkal.

Amikor egy lekérdezés megérkezik a raktárba, az IWM előrejelzi a lekérdezés költségét. Ugyanakkor az IWM valós időben figyeli a raktár rendelkezésre álló számítási kapacitását. Ezután a gépi tanulási modellek használatával az IWM előrejelzi, hogy a bejövő lekérdezés rendelkezik-e a meglévő számításhoz szükséges számítással. Ha nem rendelkezik a szükséges számítással, a rendszer hozzáadja a lekérdezést az üzenetsorhoz. Ha rendelkezik a szükséges számítással, a lekérdezés azonnal megkezdi a végrehajtást.

Az IWM körülbelül 10 másodpercenként figyeli az üzenetsort. Ha az üzenetsor nem csökken elég gyorsan, az automatikus skálázás elindul a nagyobb számítási kapacitás gyors beszerzése érdekében. Az új kapacitás hozzáadása után az üzenetsorba helyezett lekérdezések bekerülnek az új fürtökbe. Kiszolgáló nélküli SQL-raktárak használatával gyorsan új fürtök hozhatók létre, és egyszerre több fürt is létrehozható. Egy üzenetsor lekérdezéseinek maximális száma az SQL Warehouse-típusok esetében 1000.

Fürtméretek pro- és klasszikus SQL-raktárakhoz

Az ebben a szakaszban található táblázat az SQL Warehouse-fürtméreteket az Azure Databricks-fürtillesztők méretére és a feldolgozók számára képezi le. Az illesztőprogram mérete csak a profi és a klasszikus SQL-tárolókra vonatkozik.

Fürt mérete	Illesztőprogram példánytípusa (csak a pro és a klasszikus SQL-tárolókra vonatkozik)	Feldolgozók száma
2X-kicsi	Standard_E8ds_v4	1 x Standard_E8ds_v4
X-kicsi	Standard_E8ds_v4	2 x Standard_E8ds_v4
Small	Standard_E16ds_v4	4 x Standard_E8ds_v4
Közepes	Standard_E32ds_v4	8 x Standard_E8ds_v4
Nagy	Standard_E32ds_v4	16 x Standard_E8ds_v4
X-Nagy	Standard_E64ds_v4	32 x Standard_E8ds_v4
2x nagy	Standard_E64ds_v4	64 x Standard_E8ds_v4
3X nagy	Standard_E64ds_v4	128 x Standard_E8ds_v4
4X-Nagy	Standard_E64ds_v4	256 x Standard_E8ds_v4

Az összes feldolgozó példánymérete Standard_E8ds_v4.

Mindegyik illesztőprogram és feldolgozó nyolc 128 GB-os standard LRS-felügyelt lemezzel rendelkezik. A csatlakoztatott lemezek óránként kerülnek felszámításra.

Kötelező Azure vCPU-kvóta klasszikus és pro SQL-raktárakhoz

Klasszikus vagy pro SQL-raktár indításához megfelelő Azure vCPU-kvótával kell rendelkeznie az Azure-fiókban lévő Standard_E8ds_v4 példányokhoz. A szükséges vCPU-kvóta meghatározásához használja az alábbi irányelveket:

• Ha csak egy vagy két SQL-raktárral rendelkezik, győződjön meg arról, hogy 8 Azure vCPU érhető el a fürt egyes magjaihoz. Ez biztosítja, hogy megfelelő Azure vCPU-val rendelkezzen a nagyjából 24 óránként végbement adattárház újrakiépítéséhez. Ha az SQL-raktárak automatikus skálázást vagy többfürt-terheléselosztást használnak, előfordulhat, hogy növelnie kell a szorzót.
• Az SQL-raktárak számának növekedésével 4 és 8 közötti Azure vCPU-t engedélyez a fürt minden magja számára. A Databricks azt javasolja, hogy kezdjen nagyobb számmal, és monitorozza a stabilitást.
• Az SQL-raktárak által használt Azure-beli vCPU-k a Adattudomány > mérnöki vagy nem Databricks-számítási feladatok által használt fürtök által használt Azure-beli vCPU-k mellett használhatók.

További Azure vCPU-kvóta kéréséhez tekintse meg a Standard kvótát: A virtuálisgép-sorozatok korlátainak növelése az Azure dokumentációjában.

Feljegyzés

A táblázatban szereplő információk a termék vagy a régió rendelkezésre állása és a munkaterület típusa alapján változhatnak.

Várakozási sorba helyezés és automatikus skálázás profi és klasszikus SQL-raktárakhoz

Az Azure Databricks korlátozza az SQL Warehouse-hoz hozzárendelt fürtök lekérdezéseinek számát az eredmények kiszámításának költsége alapján. A fürtök raktáronkénti felskálázása a lekérdezések átviteli sebességén, a bejövő lekérdezések sebességén és az üzenetsor méretén alapul. Az Azure Databricks 10 egyidejű lekérdezéshez javasol fürtöt. Egy üzenetsor lekérdezéseinek maximális száma az SQL Warehouse-típusok esetében 1000.

Az Azure Databricks fürtöket ad hozzá az összes jelenleg futó lekérdezés, az összes várólistás lekérdezés és a következő két percben várt bejövő lekérdezések feldolgozásához szükséges idő alapján.

• Ha kevesebb, mint 2 perc, ne legyen skálázva.
• Ha 2–6 perc, adjon hozzá 1 fürtöt.
• Ha 6–12 perc, adjon hozzá 2 fürtöt.
• Ha 12–22 perc, adjon hozzá 3 fürtöt.

Ellenkező esetben az Azure Databricks 3 fürtöt és 1 fürtöt ad hozzá további 15 percenként a várt lekérdezési terheléshez.

Emellett a raktárak mindig felskálázhatók, ha egy lekérdezés 5 percet vár az üzenetsorban.

Ha a terhelés 15 percig alacsony, az Azure Databricks leskálázja az SQL Warehouse-t. Elegendő fürtöt tart fenn a maximális terhelés kezeléséhez az elmúlt 15 percben. Ha például a maximális terhelés 25 egyidejű lekérdezés volt, az Azure Databricks 3 fürtöt tart meg.

Lekérdezéssor-kezelés profi és klasszikus SQL-raktárakhoz

Az Azure Databricks várólistára állítja a lekérdezéseket, ha a raktárhoz rendelt összes fürt teljes kapacitással vagy a raktár állapotában STARTING hajt végre lekérdezéseket. Egy üzenetsor lekérdezéseinek maximális száma az SQL Warehouse-típusok esetében 1000.

A metaadat-lekérdezések (például DESCRIBE <table>) és az állapotmódosítási lekérdezések (például SET) soha nem lesznek várólistán, kivéve, ha a raktár állapotban STARTING van.