Teljesítménnyel és méretezhetőséggel kapcsolatos ellenőrzőlista a Blob Storage-hoz
A Microsoft számos bevált eljárást fejlesztett ki a nagy teljesítményű alkalmazások Blob Storage-beli fejlesztéséhez. Ez az ellenőrzőlista a fejlesztők által a teljesítmény optimalizálásához követhető főbb eljárásokat azonosítja. Tartsa szem előtt ezeket a gyakorlatokat az alkalmazás tervezésekor és a folyamat során.
Az Azure Storage méretezhetőségi és teljesítménycélokkal rendelkezik a kapacitás, a tranzakciós sebesség és a sávszélesség tekintetében. Az Azure Storage skálázhatósági céljairól további információt a standard tárfiókok méretezhetőségi és teljesítménycéljai, valamint a Blob Storage méretezhetőségi és teljesítménycéljai című témakörben talál.
Checklist
Ez a cikk a Blob Storage-alkalmazás fejlesztése során követhető ellenőrzőlistába rendezi a teljesítmény bevált eljárásait.
Méretezhetőségi célok
Ha az alkalmazás megközelíti vagy túllépi a méretezhetőségi célok bármelyikét, előfordulhat, hogy a tranzakció késése vagy szabályozása megnő. Amikor az Azure Storage szabályozza az alkalmazást, a szolgáltatás 503 (kiszolgáló foglalt) vagy 500 (művelet időtúllépése) hibakódokat ad vissza. Ezeknek a hibáknak a skálázhatósági célok korlátain belüli elkerülése fontos része az alkalmazás teljesítményének növelésének.
A Queue szolgáltatás skálázhatósági céljairól további információt az Azure Storage skálázhatósági és teljesítménycéljaiban talál.
Tárfiókok maximális száma
Ha egy adott előfizetés/régió kombinációhoz engedélyezett tárfiókok maximális számát közelíti meg, értékelje ki a forgatókönyvet, és állapítsa meg, hogy az alábbi feltételek bármelyike érvényes-e:
- Tárfiókokkal tárolja a nem felügyelt lemezeket, és hozzáadja ezeket a lemezeket a virtuális gépekhez? Ebben a forgatókönyvben a Microsoft a felügyelt lemezek használatát javasolja. A felügyelt lemezek automatikusan és anélkül méretezhetők, hogy külön tárfiókokat kellene létrehozni és kezelni. További információ: Bevezetés az Azure-beli felügyelt lemezek használatába
- Ügyfélenként egy tárfiókot használ adatelkülönítés céljából? Ebben a forgatókönyvben a Microsoft azt javasolja, hogy minden ügyfélhez használjon blobtárolót a teljes tárfiók helyett. Az Azure Storage mostantól lehetővé teszi az Azure-szerepkörök tárolónkénti hozzárendelését. További információért lásd: Azure-szerepkör hozzárendelése a blobadatokhoz való hozzáféréshez.
- Több tárfiókot használ szegmensekre a bejövő forgalom, a kimenő forgalom, az I/O-műveletek másodpercenkénti (IOPS) vagy kapacitásának növeléséhez? Ebben a forgatókönyvben a Microsoft azt javasolja, hogy használja ki a tárfiókok megnövekedett korlátait, hogy lehetőség szerint csökkentse a számítási feladathoz szükséges tárfiókok számát. Lépjen kapcsolatba az Azure ügyfélszolgálatával , és kérje a tárfiókra vonatkozó megnövekedett korlátokat.
Kapacitás- és tranzakciós célok
Ha az alkalmazás egy tárfiók méretezhetőségi céljaihoz közelít, fontolja meg az alábbi módszerek egyikének alkalmazását:
- Ha az alkalmazás eléri a tranzakciós célt, fontolja meg a blokkblobtárfiókok használatát, amelyek magas tranzakciós sebességre és alacsony és konzisztens késésre vannak optimalizálva. További információkat az Azure Storage-fiókok áttekintésében találhat.
- Gondolja át azt a számítási feladatot, amely miatt az alkalmazás megközelíti vagy túllépi a méretezhetőségi célt. Meg tudja másképp tervezni, hogy kevesebb sávszélességet vagy kapacitást használjon, vagy kevesebb tranzakciót használjon?
- Ha az alkalmazásnak meg kell haladnia az egyik méretezhetőségi célt, hozzon létre több tárfiókot, és particionálja az alkalmazás adatait a több tárfiók között. Ha ezt a mintát használja, ügyeljen arra, hogy az alkalmazást úgy tervezzen meg, hogy a jövőben további tárfiókokat lehessen hozzáadni a terheléselosztáshoz. Maguk a tárfiókok a tárolt adatok, a tranzakciók vagy az átvitt adatok használatán kívül más költségekkel sem járnak.
- Ha az alkalmazás megközelíti a sávszélesség-célokat, fontolja meg az adatok ügyféloldali tömörítését az adatok Azure Storage-ba való küldéséhez szükséges sávszélesség csökkentése érdekében. Bár az adatok tömörítése csökkentheti a sávszélességet és javíthatja a hálózati teljesítményt, negatív hatással lehet a teljesítményre is. Értékelje ki az ügyféloldali adattömörítésre és dekompresszióra vonatkozó további feldolgozási követelmények teljesítményre gyakorolt hatását. Ne feledje, hogy a tömörített adatok tárolása megnehezítheti a hibaelhárítást, mert a standard eszközökkel nehezebb lehet megtekinteni az adatokat.
- Ha az alkalmazás megközelíti a méretezhetőségi célokat, győződjön meg arról, hogy exponenciális visszalépést használ az újrapróbálkozáshoz. A legjobb, ha megpróbálja elkerülni a méretezhetőségi célok elérését a cikkben ismertetett javaslatok végrehajtásával. Ha azonban exponenciális visszalépést használ az újrapróbálkozáshoz, azzal megakadályozza, hogy az alkalmazás gyorsan újrapróbálkozjon, ami ronthat a szabályozáson. További információ: Időtúllépési és kiszolgálói foglaltsági hibák.
Több ügyfél egyidejűleg fér hozzá egyetlen blobhoz
Ha egyszerre nagy számú ügyfél fér hozzá egyetlen blobhoz, akkor blobonként és tárfiókonkénti méretezhetőségi célokat is figyelembe kell vennie. Az egy blobhoz hozzáférő ügyfelek pontos száma olyan tényezőktől függ, mint például a blobot egyidejűleg kérő ügyfelek száma, a blob mérete és a hálózati feltételek.
Ha a blob egy CDN-en keresztül terjeszthető, például egy webhelyről letöltött képeken vagy videókon keresztül, akkor használhat CDN-t. További információkért lásd a Tartalomterjesztés című szakaszt.
Más forgatókönyvekben, például tudományos szimulációkban, ahol az adatok bizalmasak, két lehetőség közül választhat. Az első az, hogy a számítási feladat hozzáférését úgy vizsgáljuk meg, hogy a blob egy ideig legyen elérhető, és ne egyszerre legyen elérhető. Azt is megteheti, hogy ideiglenesen több tárfiókba másolja a blobot, hogy növelje a blobonkénti és a tárfiókok közötti teljes IOPS-t. Az eredmények az alkalmazás viselkedésétől függően változnak, ezért mindenképpen tesztelje az egyidejűségi mintákat a tervezés során.
Sávszélesség és műveletek blobonként
Egyetlen blob másodpercenként legfeljebb 500 kérést támogat. Ha több ügyféllel is be kell olvasnia ugyanazt a blobot, és túllépheti ezt a korlátot, fontolja meg a blokkblobtároló-fiók használatát. A blokkblobtárfiókok magasabb kérési gyakoriságot vagy másodpercenkénti I/O-műveleteket (IOPS) biztosítanak.
Egy tartalomkézbesítési hálózat (CDN), például az Azure CDN használatával is terjesztheti a műveleteket a blobon. Az Azure CDN-ről további információt az Azure CDN áttekintésében talál.
Particionálás
Annak megismerése, hogy az Azure Storage hogyan particionálja a blobadatokat, hasznos a teljesítmény növelése érdekében. Az Azure Storage gyorsabban tudja kiszolgálni az adatokat egyetlen partíción, mint a több partícióra kiterjedő adatok. A blobok megfelelő elnevezésével javíthatja az olvasási kérelmek hatékonyságát.
A Blob Storage tartományalapú particionálási sémát használ a skálázáshoz és a terheléselosztáshoz. Minden blobhoz tartozik egy partíciókulcs, amely a teljes blobnévből (account+container+blob) áll. A partíciókulcs a blobadatok tartományokba való particionálására szolgál. A tartományok ezután terheléselosztással vannak elosztva a Blob Storage-ban.
A tartományalapú particionálás azt jelenti, hogy a lexikális rendezést használó elnevezési konvenciók (például a mypayroll, a myperformance, a myemployees stb.) vagy az időbélyegek (log20160101, log20160102, log20160102 stb.) nagyobb valószínűséggel eredményezik, hogy a partíciók ugyanazon a partíciókiszolgálón találhatók, amíg a megnövekedett terhelés megköveteli, hogy kisebb tartományokra legyenek felosztva. Az ugyanazon a partíciókiszolgálón található blobok együttes elhelyezése javítja a teljesítményt, ezért a teljesítményfejlesztés fontos része a blobok elnevezése oly módon, hogy azok a leghatékonyabban legyenek rendszerezve.
A tárolón belüli összes blobot például egyetlen kiszolgáló kiszolgálhatja, amíg a blobok terhelése nem igényli a partíciótartományok további elosztását. Hasonlóképpen, a lexikális sorrendben elrendezett, könnyen betöltött fiókok egy csoportját egyetlen kiszolgáló is kiszolgálhatja, amíg az egyik vagy az összes fiók terhelése megköveteli, hogy több partíciókiszolgálóra legyenek felosztva.
Minden terheléselosztási művelet hatással lehet a tárolási hívások késésére a művelet során. A szolgáltatásnak az egyetlen partíciókiszolgáló méretezhetősége korlátozza a partíciók felé irányuló hirtelen adatforgalom kezelését, amíg a terheléselosztási művelet be nem indul, és kiegyensúlyozza a partíciókulcs-tartományt.
Néhány ajánlott eljárást követve csökkentheti az ilyen műveletek gyakoriságát.
Ha lehetséges, használjon 256 KiB-nél nagyobb blob- vagy blokkméreteket standard és prémium szintű tárfiókokhoz. A nagyobb blob- vagy blokkméretek automatikusan aktiválják a nagy átviteli sebességű blokkblobokat. A nagy átviteli sebességű blokkblobok nagy teljesítményű betöltést biztosítanak, amelyet a partíció elnevezése nem érint.
Vizsgálja meg a fiókok, tárolók, blobok, táblák és üzenetsorok elnevezési konvencióját. Fontolja meg a fiók, tároló vagy blobnevek háromjegyű kivonatolással történő előtagolását az igényeinek leginkább megfelelő kivonatoló függvénnyel.
Ha időbélyegek vagy numerikus azonosítók használatával rendszerezi az adatokat, győződjön meg arról, hogy nem csak hozzáfűző (vagy csak előzetes) forgalmi mintát használ. Ezek a minták nem alkalmasak tartományalapú particionálási rendszerekhez. Ezek a minták azt eredményezhetik, hogy az összes forgalom egyetlen partícióra kerül, és korlátozza a rendszer hatékony terheléselosztását.
Ha például olyan napi műveletei vannak, amelyek egy olyan blobot használnak, amely időbélyeggel (például yymmdd) rendelkezik, akkor a napi művelet összes forgalma egyetlen blobra lesz irányítva, amelyet egyetlen partíciókiszolgáló szolgál ki. Fontolja meg, hogy a blobonkénti és a partíciónkénti korlátok megfelelnek-e az igényeinek, és szükség esetén fontolja meg a művelet több blobra való lebontását. Hasonlóképpen, ha idősoradatokat tárol a táblákban, az összes forgalom a kulcsnévtér utolsó részére irányítható. Numerikus azonosítók használata esetén az azonosító előtagja háromjegyű kivonat. Időbélyegek használata esetén az időbélyeg előtagja a másodpercértékkel, például ssyyyymmd. Ha az alkalmazás rendszeresen végez listázási és lekérdezési műveleteket, válasszon egy kivonatoló függvényt, amely korlátozza a lekérdezések számát. Bizonyos esetekben elegendő lehet egy véletlenszerű előtag.
Az Azure Storage-ban használt particionálási sémával kapcsolatos további információkért lásd : Azure Storage: Magas rendelkezésre állású felhőalapú tárolási szolgáltatás erős konzisztenciával.
Networking
Az alkalmazás fizikai hálózati korlátai jelentős hatással lehetnek a teljesítményre. Az alábbi szakaszok néhány olyan korlátozást ismertetnek, amelyekkel a felhasználók találkozhatnak.
Ügyfélhálózati képesség
A sávszélesség és a hálózati kapcsolat minősége fontos szerepet játszik az alkalmazások teljesítményében, az alábbi szakaszokban leírtak szerint.
Átviteli sebesség
A sávszélesség esetében a probléma gyakran az ügyfél képességei. A nagyobb Azure-példányok nagyobb kapacitású hálózati adapterekkel rendelkeznek, ezért érdemes megfontolni egy nagyobb példány vagy több virtuális gép használatát, ha nagyobb hálózati korlátokra van szüksége egyetlen gépről. Ha helyszíni alkalmazásból éri el az Azure Storage-t, ugyanez a szabály érvényes: ismerje meg az ügyféleszköz hálózati képességeit és az Azure Storage helyéhez való hálózati kapcsolatot, és szükség szerint javítsa őket, vagy tervezze meg az alkalmazást, hogy a képességeiknek megfelelően működjön.
Kapcsolat minősége
A hálózati használathoz hasonlóan ne feledje, hogy a hibákat és csomagvesztést eredményező hálózati feltételek lassítják a hatékony átviteli sebességet. A WireShark vagy a NetMon használata segíthet a probléma diagnosztizálásában.
Location
Bármely elosztott környezetben az ügyfél kiszolgálóhoz közeli elhelyezése a legjobb teljesítményt nyújtja. A legalacsonyabb késéssel rendelkező Azure Storage eléréséhez az ügyfél számára a legjobb hely ugyanabban az Azure-régióban található. Ha például van egy Azure-webalkalmazása, amely az Azure Storage-t használja, akkor mindkettőt egyetlen régióban, például az USA nyugati régiójában vagy Délkelet-Ázsiában találja. Az erőforrások közös keresése csökkenti a késést és a költségeket, mivel az egyetlen régión belüli sávszélesség-használat ingyenes.
Ha az ügyfélalkalmazások hozzáférnek az Azure Storage-hoz, de nem az Azure-ban vannak üzemeltetve, például mobileszköz-alkalmazásokat vagy helyszíni vállalati szolgáltatásokat, akkor a tárfióknak az ügyfelekhez közeli régióban való elhelyezése csökkentheti a késést. Ha az ügyfelek széles körben vannak elosztva (például néhány Észak-Amerika és néhány Európában), akkor érdemes lehet régiónként egy tárfiókot használni. Ez a megközelítés könnyebben implementálható, ha az alkalmazás által tárolt adatok egyedi felhasználókra vonatkoznak, és nem igényelnek adatok replikálását a tárfiókok között.
A blobtartalmak széles körű terjesztéséhez használjon tartalomszolgáltató hálózatot, például az Azure CDN-t. Az Azure CDN-ről további információt az Azure CDN-ben talál.
SAS és CORS
Tegyük fel, hogy engedélyeznie kell a felhasználó webböngészőjében vagy egy mobiltelefonos alkalmazásban futó kódokat, például a JavaScriptet az Azure Storage-adatok eléréséhez. Az egyik módszer egy proxyként működő szolgáltatásalkalmazás létrehozása. A felhasználó eszköze a szolgáltatással hitelesít, ami viszont engedélyezi az Azure Storage-erőforrásokhoz való hozzáférést. Ily módon elkerülheti a tárfiókkulcsok nem biztonságos eszközökön való felfedését. Ez a megközelítés azonban jelentős többletterhelést jelent a szolgáltatásalkalmazáson, mivel a felhasználó eszköze és az Azure Storage között átvitt összes adatnak át kell haladnia a szolgáltatásalkalmazáson.
Elkerülheti, hogy egy szolgáltatásalkalmazást proxyként használjon az Azure Storage-hoz közös hozzáférésű jogosultságkódok (SAS) használatával. Az SAS használatával engedélyezheti, hogy a felhasználó eszköze egy korlátozott hozzáférési jogkivonat használatával közvetlenül az Azure Storage-ba küldjön kéréseket. Ha például egy felhasználó fel szeretne tölteni egy fényképet az alkalmazásba, akkor a szolgáltatásalkalmazás létrehozhat egy SAS-t, és elküldheti azt a felhasználó eszközére. Az SAS-jogkivonat engedélyt adhat egy Azure Storage-erőforrásba való írásra egy megadott ideig, amely után az SAS-jogkivonat lejár. További információ az SAS-ről: Korlátozott hozzáférés biztosítása az Azure Storage-erőforrásokhoz közös hozzáférésű jogosultságkódok (SAS) használatával.
A webböngészők általában nem engedélyezik a JavaScript használatát az egyik tartomány webhelye által üzemeltetett lapon bizonyos műveletek, például írási műveletek egy másik tartományba történő végrehajtásához. Az azonos eredetű szabályzatként ismert házirend megakadályozza, hogy egy rosszindulatú szkript egy oldalon hozzáférjen egy másik weblap adataihoz. Az azonos eredetű szabályzat azonban korlátozhatja a felhőben történő megoldáskészítést. A forrásközi erőforrás-megosztás (CORS) egy böngészőfunkció, amely lehetővé teszi a céltartomány számára, hogy a forrástartományból származó kéréseket megbízhatónak minősítő böngészővel kommunikáljon.
Tegyük fel például, hogy egy Azure-ban futó webalkalmazás egy Azure Storage-fiókba küld egy erőforrást. A webalkalmazás a forrástartomány, a tárfiók pedig a céltartomány. Bármelyik Azure Storage-szolgáltatáshoz konfigurálhatja a CORS-t, hogy a forrástartományból érkező kéréseket az Azure Storage megbízhatónak minősítő webböngészővel kommunikáljon. A CORS-ról további információt az Azure Storage forrásközi erőforrás-megosztási (CORS) támogatásában talál.
Az SAS és a CORS segítségével elkerülheti a webalkalmazás felesleges terhelését.
Gyorsítótárazás
A gyorsítótárazás fontos szerepet játszik a teljesítményben. A következő szakaszok a gyorsítótárazási ajánlott eljárásokat ismertetik.
Adatok beolvasása
Általánosságban elmondható, hogy az adatok egyszer történő olvasása előnyösebb, ha kétszer olvassa be azokat. Vegyük példaként azt a webalkalmazást, amely lekért egy 50 MiB-blobot az Azure Storage-ból, hogy tartalomként szolgáljon a felhasználó számára. Ideális esetben az alkalmazás helyileg gyorsítótárazza a blobot a lemezre, majd lekéri a gyorsítótárazott verziót a későbbi felhasználói kérésekhez.
A blobok lekérésének elkerülése érdekében, ha a gyorsítótárazás óta nem lett módosítva, akkor a GET műveletet feltételes fejléccel kell minősíteni a módosítási időhöz. Ha az utolsó módosítás időpontja a blob gyorsítótárazása után következik be, a blob lekérése és ismételt gyorsítótárazása. Ellenkező esetben a gyorsítótárazott blob lekéri az optimális teljesítményt.
Dönthet úgy is, hogy az alkalmazást úgy tervezi meg, hogy feltételezze, hogy a blob a lekérés után rövid ideig változatlan marad. Ebben az esetben az alkalmazásnak nem kell ellenőriznie, hogy a blob módosult-e az adott időszakban.
A konfigurációs adatok, a keresési adatok és az alkalmazás által gyakran használt egyéb adatok kiválóan alkalmasak a gyorsítótárazásra.
A feltételes fejlécek használatáról további információt a Blob service-műveletek feltételes fejléceinek megadása című témakörben talál.
Adatok feltöltése kötegekben
Bizonyos esetekben helyileg összesítheti az adatokat, majd rendszeres időközönként feltöltheti őket egy kötegbe ahelyett, hogy minden egyes adatrészt azonnal feltöltené. Tegyük fel például, hogy egy webalkalmazás megőrzi a tevékenységek naplófájlját. Az alkalmazás feltöltheti az összes tevékenység részleteit, amikor egy táblával történik (ami sok tárolási műveletet igényel), vagy mentheti a tevékenység részleteit egy helyi naplófájlba, majd rendszeresen feltöltheti az összes tevékenységadatokat tagolt fájlként egy blobba. Ha minden naplóbejegyzés mérete 1 KB, több ezer bejegyzést tölthet fel egyetlen tranzakcióban. Egyetlen tranzakció legfeljebb 64 MiB méretű blob feltöltését támogatja. Az alkalmazásfejlesztőnek meg kell terveznie az ügyféleszköz vagy a feltöltési hibák lehetőségét. Ha a tevékenységadatokat nem egyetlen tevékenységhez, hanem időintervallumra kell letölteni, akkor a Blob Storage használata ajánlott a Table Storage használatával.
.NET-konfiguráció
A .NET-keretrendszer használó projektek esetében ez a szakasz felsorol néhány gyors konfigurációs beállítást, amelyekkel jelentős teljesítménybeli javulást érhet el. Ha nem .NET-nyelvet használ, ellenőrizze, hogy a választott nyelven vannak-e hasonló fogalmak.
Az alapértelmezett kapcsolatkorlát növelése
Megjegyzés:
Ez a szakasz a .NET-keretrendszer használó projektekre vonatkozik, mivel a kapcsolatkészletezést a ServicePointManager osztály vezérli. A .NET Core jelentős változást vezetett be a kapcsolatkészlet kezelése körül, ahol a kapcsolatkészletezés a HttpClient szintjén történik, és a készlet mérete alapértelmezés szerint nem korlátozott. Ez azt jelenti, hogy a HTTP-kapcsolatok automatikusan skálázódnak a számítási feladatok kielégítése érdekében. A .NET legújabb verziójának használata ajánlott, ha lehetséges, a teljesítménybeli fejlesztések előnyeinek kihasználásához.
Az .NET-keretrendszer használó projektek esetében az alábbi kóddal 100-ra növelheti az alapértelmezett kapcsolati korlátot (amely ügyfélkörnyezetben általában kettő, kiszolgálókörnyezetben tíz). Az értéket általában körülbelül az alkalmazás által használt szálak számának megfelelő értékre kell állítania. A kapcsolatok megnyitása előtt állítsa be a kapcsolatkorlátot.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
A .NET-keretrendszer kapcsolatkészletkorlátairól további információt a .NET-keretrendszer Csatlakozás ion Pool Limits és az új Azure SDK for .NET című témakörben talál.
Más programozási nyelvek esetén a dokumentációból megtudhatja, hogyan állíthatja be a kapcsolati korlátot.
Szálak minimális számának növelése
Ha szinkron hívásokat és aszinkron feladatokat használ, érdemes lehet növelni a szálak számát a szálkészletben:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
További információ: ThreadPool.SetMinThreads metódus.
Kötetlen párhuzamosság
Bár a párhuzamosság kiválóan alkalmas a teljesítményre, ügyeljen a kötetlen párhuzamosság használatára, ami azt jelenti, hogy nincs korlátozva a szálak vagy párhuzamos kérések száma. Ügyeljen arra, hogy korlátozza az adatok feltöltésére vagy letöltésére irányuló párhuzamos kérelmeket, hogy ugyanabban a tárfiókban több partícióhoz férhessen hozzá, vagy hogy ugyanabban a partícióban több elemhez is hozzáférhessen. Ha a párhuzamosság nem kötött, az alkalmazás túllépheti az ügyféleszköz képességeit vagy a tárfiók méretezhetőségi céljait, ami hosszabb késéseket és szabályozást eredményez.
Ügyfélkódtárak és -eszközök
A legjobb teljesítmény érdekében mindig a Microsoft által biztosított legújabb ügyfélkódtárakat és eszközöket használja. Az Azure Storage-ügyfélkódtárak számos nyelvhez elérhetők. Az Azure Storage a PowerShellt és az Azure CLI-t is támogatja. A Microsoft aktívan fejleszti ezeket az ügyfélkódtárakat és eszközöket a teljesítmény szem előtt tartásával, naprakészen tartja őket a legújabb szolgáltatásverziókkal, és biztosítja, hogy belsőleg kezelje a bevált teljesítménybeli eljárások nagy részét.
Tipp.
Az ABFS-illesztőt úgy tervezték, hogy elhárítsa a WASB eredendő hiányosságait. A Microsoft az ABFS-illesztőprogram használatát javasolja a WASB-illesztőprogramon keresztül, mivel az ABFS-illesztő kifejezetten big data-elemzésre van optimalizálva.
Szolgáltatáshibák kezelése
Az Azure Storage hibát ad vissza, ha a szolgáltatás nem tud feldolgozni egy kérést. Az Azure Storage által adott forgatókönyvben visszaadott hibák megértése hasznos a teljesítmény optimalizálásához. A gyakori hibakódok listáját a Common REST API hibakódjaiban találja.
Időtúllépési és kiszolgálói foglaltsági hibák
Az Azure Storage szabályozhatja az alkalmazást, ha megközelíti a méretezhetőség korlátait. Bizonyos esetekben előfordulhat, hogy az Azure Storage valamilyen átmeneti feltétel miatt nem tudja kezelni a kéréseket. Mindkét esetben előfordulhat, hogy a szolgáltatás 503(kiszolgáló foglalt) vagy 500 (időtúllépés) hibát ad vissza. Ezek a hibák akkor is előfordulhatnak, ha a szolgáltatás újraegyensúlyozza az adatpartíciókat a nagyobb átviteli sebesség érdekében. Az ügyfélalkalmazásnak általában újra kell próbálkoznia az ilyen hibákat okozó művelettel. Ha azonban az Azure Storage azért szabályozza az alkalmazást, mert meghaladja a méretezhetőségi célokat, vagy ha a szolgáltatás valamilyen más okból nem tudta kiszolgálni a kérést, az agresszív újrapróbálkozások tovább ronthatják a problémát. Az exponenciális visszatartási újrapróbálkozási szabályzat használata ajánlott, és az ügyfélkódtárak alapértelmezés szerint ezt a viselkedést használják. Előfordulhat például, hogy az alkalmazás 2 másodperc, majd 4 másodperc, 10 másodperc, majd 30 másodperc után újra próbálkozik, majd teljesen feladja. Ily módon az alkalmazás jelentősen csökkenti a szolgáltatás terhelését ahelyett, hogy fokozná a szabályozáshoz vezető viselkedést.
Csatlakozás tivitási hibák azonnal újrapróbálhatók, mert nem a szabályozás eredménye, és várhatóan átmenetiek lesznek.
Nem újrapróbálkozható hibák
Az ügyfélkódtárak kezelik az újrapróbálkozásokat, és tisztában vannak azzal, hogy mely hibák újrapróbálkozhatók, és melyeket nem lehet újrapróbálkozni. Ha azonban közvetlenül az Azure Storage REST API-t hívja meg, vannak olyan hibák, amelyeket nem szabad újrapróbálkoznia. Egy 400-ás (hibás kérelem) hiba például azt jelzi, hogy az ügyfélalkalmazás olyan kérelmet küldött, amely nem feldolgozható, mert nem volt a várt formában. A kérés újraküldése minden alkalommal ugyanazt a választ eredményezi, így nincs értelme újrapróbálkozni. Ha közvetlenül az Azure Storage REST API-t hívja meg, vegye figyelembe a lehetséges hibákat, és hogy újra kell-e próbálkoznia.
Az Azure Storage hibakódjaival kapcsolatos további információkért tekintse meg az Állapot és a hibakódok című témakört.
Blobok másolása és áthelyezése
Az Azure Storage számos megoldást kínál a blobok másolására és áthelyezésére egy tárfiókon belül, a tárfiókok között, valamint a helyszíni rendszerek és a felhő között. Ez a szakasz néhány beállítást a teljesítményre gyakorolt hatásuk szempontjából ismertet. Az adatok Blob Storage-ba vagy onnan történő hatékony átviteléről további információt az Azure-megoldás kiválasztása az adatátvitelhez című témakörben talál.
Blobmásolási API-k
Blobok tárfiókok közötti másolásához használja a Tiltás tiltása URL-címről műveletet. Ez a művelet szinkronizálva másolja az adatokat bármely URL-forrásból egy blokkblobba. A művelet használata jelentősen csökkentheti a Put Block from URL szükséges sávszélességet, amikor adatokat migrál a tárfiókok között. Mivel a másolási művelet a szolgáltatás oldalán történik, nem kell letöltenie és újra feltöltenie az adatokat.
Ha ugyanabban a tárfiókban szeretne adatokat másolni, használja a Blob másolása műveletet. Az adatok ugyanazon tárfiókon belüli másolása általában gyorsan befejeződik.
Az AzCopy használata
Az AzCopy parancssori segédprogram egy egyszerű és hatékony lehetőség a blobok tömeges átvitelére a tárfiókokba, onnan és a tárfiókok között. Az AzCopy erre a forgatókönyvre van optimalizálva, és magas átviteli sebesség érhető el. Az AzCopy 10-es verziója a blobadatok tárfiókok közötti másolására használja a Put Block From URL műveletet. További információ: Adatok másolása vagy áthelyezése az Azure Storage-ba az AzCopy v10 használatával.
Az Azure Data Box használata
Nagy mennyiségű adat Blob Storage-ba való importálásához fontolja meg az Azure Data Box család offline átvitelhez való használatát. A Microsoft által biztosított Data Box-eszközök jó választás nagy mennyiségű adat Azure-ba való áthelyezéséhez, ha az idő, a hálózati rendelkezésre állás vagy a költségek korlátozottak. További információkért tekintse meg az Azure DataBox dokumentációját.
Tartalomterjesztés
Néha egy alkalmazásnak ugyanazt a tartalmat kell kiszolgálnia sok felhasználónak (például egy webhely kezdőlapján használt termékbemutató videónak), amely ugyanabban vagy több régióban található. Ebben a forgatókönyvben használjon tartalomkézbesítési hálózatot (CDN), például az Azure Front Doort. Az Azure Front Door a Microsoft modern felhőalapú CDN-je, amely gyors, megbízható és biztonságos hozzáférést biztosít a felhasználók és az alkalmazások statikus és dinamikus webes tartalmai között világszerte. Az Azure Front Door a Microsoft globális peremhálózatával , több száz globális és helyi jelenléti ponttal (PoPs) biztosítja a Blob Storage-tartalmat. A CDN-ek általában sokkal magasabb kimenő forgalomkorlátokat támogatnak, mint egy tárfiók, és nagyobb késést biztosítanak a tartalom más újraküldő példányokra való továbbításához.
Az Azure Front Doorról további információt az Azure Front Doorban talál.
Metaadatok használata
A Blob szolgáltatás támogatja a HEAD-kéréseket, amelyek blobtulajdonságokat vagy metaadatokat tartalmazhatnak. Ha például az alkalmazásnak szüksége van az Exif (cserélhető képformátum) adatokra egy fényképből, lekérheti a fényképet, és kinyerheti azt. A sávszélesség megtakarítása és a teljesítmény javítása érdekében az alkalmazás tárolhatja az Exif-adatokat a blob metaadataiban, amikor az alkalmazás feltölti a fényképet. Ezután csak HEAD-kéréssel kérheti le az Exif-adatokat a metaadatokban. Ha csak metaadatokat kér le, és nem a blob teljes tartalmát, jelentős sávszélességet takarít meg, és csökkenti az Exif-adatok kinyeréséhez szükséges feldolgozási időt. Ne feledje, hogy blobonként 8 KiB metaadat tárolható.
Fiók- és tároló metaadatainak frissítései
A fiók és a tároló metaadatai a társzolgáltatásban vannak propagálva abban a régióban, ahol a fiók található. A metaadatok teljes propagálása a művelettől függően akár 60 másodpercet is igénybe vehet. Például:
- Ha ugyanabban a régióban gyorsan hoz létre, töröl és új fiókokat ugyanazzal a fióknévvel, győződjön meg arról, hogy 60 másodpercet vár a fiókállapot teljes propagálására, vagy a kérések sikertelenek lehetnek.
- Ha tárolón hoz létre tárolt hozzáférési szabályzatot, a szabályzat érvénybe lépése akár 30 másodpercet is igénybe vehet.
Adatátviteli teljesítmény finomhangolása
Amikor egy alkalmazás adatokat továbbít az Azure Storage-ügyfélkódtár használatával, számos tényező befolyásolhatja a sebességet, a memóriahasználatot, sőt a kérés sikerességét vagy sikertelenségét is. Az adatátviteli teljesítmény és a megbízhatóság maximalizálása érdekében fontos, hogy proaktív módon konfigurálja az ügyfélkódtár-átviteli lehetőségeket az alkalmazás által futtatott környezet alapján. További információ: Feltöltések és letöltések teljesítményhangolása.
Blobok gyors feltöltése
A blobok gyors feltöltéséhez először határozza meg, hogy egy vagy több blobot tölt-e fel. Az alábbi útmutató segítségével meghatározhatja a forgatókönyvtől függően használni kívánt megfelelő módszert. Ha az Azure Storage-ügyfélkódtárat használja adatátvitelhez, további útmutatásért tekintse meg az adatátvitel teljesítményhangolását .
Egy nagy blob gyors feltöltése
Egyetlen nagy blob gyors feltöltéséhez az ügyfélalkalmazás párhuzamosan töltheti fel a blokkjait vagy lapjait, figyelembe véve az egyes blobok és a tárfiók egészének méretezhetőségi céljait. Az Azure Storage-ügyfélkódtárak támogatják a párhuzamos feltöltést. Más támogatott nyelvek ügyfélkódtárai hasonló lehetőségeket biztosítanak.
Sok blob gyors feltöltése
Ha sok blobot szeretne gyorsan feltölteni, töltse fel párhuzamosan a blobokat. A párhuzamos feltöltés gyorsabb, mint egy blob egyidejű feltöltése párhuzamos blokkfeltöltéssel, mivel a feltöltés a tárolási szolgáltatás több partíciójára is kiterjed. Az AzCopy alapértelmezés szerint párhuzamosan végzi a feltöltéseket, és ebben a forgatókönyvben ajánlott. További információ: AzCopy használatának első lépései.
A megfelelő blobtípus kiválasztása
Az Azure Storage támogatja a blokkblobokat, a hozzáfűző blobokat és a lapblobokat. Egy adott használati forgatókönyv esetében a blobtípus kiválasztása befolyásolja a megoldás teljesítményét és méretezhetőségét.
A blokkblobok akkor megfelelőek, ha nagy mennyiségű adatot szeretne hatékonyan feltölteni. Például egy olyan ügyfélalkalmazás, amely fényképeket vagy videókat tölt fel a Blob Storage-ba, blokkblobokat célozna meg.
A hozzáfűző blobok hasonlóak a blokkblobokhoz, amelyek blokkokból állnak. Hozzáfűző blob módosításakor a blokkok csak a blob végéhez lesznek hozzáadva. A hozzáfűző blobok olyan helyzetekben hasznosak, mint a naplózás, amikor egy alkalmazásnak adatokat kell hozzáadnia egy meglévő blobhoz.
Az oldalblobok akkor megfelelőek, ha az alkalmazásnak véletlenszerű írásokat kell végeznie az adatokon. Az Azure-beli virtuálisgép-lemezek például lapblobokként vannak tárolva. További információ: A blokkblobok, a hozzáfűző blobok és a lapblobok ismertetése.