Megosztás a következőn keresztül:

Blobadatok hozzáférési szintjei

  • Cikk

A felhőben tárolt adatok exponenciális ütemben nőnek. A bővülő tárolási igények költségeinek kezeléséhez hasznos lehet az adatok rendszerezése annak alapján, hogy milyen gyakran lesznek elérhetők, és mennyi ideig őrizzük meg azokat. Az Azure Storage különböző hozzáférési szinteket kínál, így a blobadatok a használatuktól függően a legköltséghatékonyabb módon tárolhatók. Az Azure Storage hozzáférési szintjei a következők:

  • Gyakori elérésű réteg – A gyakran használt vagy módosított adatok tárolására optimalizált online réteg. A gyakori elérésű réteg a legmagasabb tárolási költségekkel rendelkezik, de a legalacsonyabb hozzáférési költségekkel.
  • Ritka elérésű réteg – Olyan online réteg, amely ritkán elért vagy módosított adatok tárolására van optimalizálva. A ritka elérésű rétegben lévő adatokat legalább 30 napig kell tárolni. A ritka elérésű réteg alacsonyabb tárolási és magasabb hozzáférési költségekkel rendelkezik a gyakori elérésű szinthez képest.
  • Hideg réteg – Olyan online réteg, amely ritkán elérhető vagy módosított adatok tárolására van optimalizálva, de még mindig gyors lekérést igényel. A hideg rétegben lévő adatokat legalább 90 napig kell tárolni. A hideg tárolási szintnek alacsonyabbak a tárolási és magasabbak az elérési költségei a hűvös tárolási szinthez képest.
  • Archív szint – Olyan offline réteg, amely ritkán elérhető adatok tárolására van optimalizálva, és amely rugalmas késési követelményekkel rendelkezik az órák sorrendjében. Az archív szinten lévő adatokat legalább 180 napig kell tárolni.

Az Azure Storage kapacitáskorlátai a fiók szintjén vannak megadva, nem pedig a hozzáférési szintnek megfelelően. Dönthet úgy, hogy egy szinten maximalizálja a kapacitáshasználatot, vagy elosztja a kapacitást két vagy több szinten.

Feljegyzés

A hozzáférési szint beállítása csak blokkblobokon engedélyezett. A hozzáfűző és lapblobok nem támogatottak.

Online hozzáférési szintek

Ha az adatokat online hozzáférési szinten (forró, hűvös vagy hideg) tárolják, a felhasználók azonnal hozzáférhetnek azokhoz. A gyakori elérésű szint a legjobb választás az aktív használatban lévő adatokhoz. Az alacsony vagy hideg szint ideális olyan adatokhoz, amelyeket ritkán érnek el, de továbbra is elérhetőnek kell lennie olvasáshoz és íráshoz.

A gyakori elérésű réteg használati forgatókönyvei például a következők:

  • Az aktív használatban lévő vagy várt adatok gyakori olvasást és írást igényelnek.
  • A feldolgozásra és végül a ritka hozzáférési rétegbe való áttelepítésre előkészített adatok.

A hűvös és ritka elérésű hozzáférési szintek használati forgatókönyvei a következők:

  • Rövid távú adatmentés és vészhelyreállítás.
  • A gyakran nem használt, de az azonnali hozzáféréshez szükséges régebbi adatkészletek várhatóan elérhetők lesznek.
  • Nagy adatkészletek, amelyeket költséghatékony módon kell tárolni, miközben más adatok gyűjtése folyamatban van feldolgozásra.

Ha meg szeretné tudni, hogyan helyezhet át egy blobot a gyakori, ritka elérésű vagy hideg szintre, olvassa el a blob hozzáférési szintjének beállítása című témakört.

A hűvös és hideg rétegek adatai valamivel alacsonyabb rendelkezésre állással rendelkeznek, de ugyanolyan magas tartósságot, lekérési késést és átviteli sebességet kínálnak, mint a forró réteg. A hideg vagy hűvös rétegben lévő adatok esetében a kissé alacsonyabb rendelkezésre állás és a magasabb hozzáférési költségek elfogadható kompromisszumot jelenthetnek az általánosságban alacsonyabb tárolási költségekért, a forró réteghez képest. További információt a tárolók rendelkezésreállási szolgáltatási szintjeit ismertető szakaszban talál.

A blobok korai törlési büntetést vonnak maguk után, ha törölték, felülírták vagy áthelyezték őket egy másik szintre, mielőtt a szint által megkövetelt minimális napok száma megtelt volna. Például egy általános célú v2-fiók hideg rétegében lévő blobra korai törlési büntetés vonatkozik, ha törlik vagy áthelyezik egy másik szintre, mielőtt 30 nap eltelt volna. A hideg rétegben lévő blobok esetében a törlési büntetés érvényes, ha 90 nap letelte előtt törlik vagy áthelyezik egy másik szintre. A díj számlázása időarányosan történik. Ha például egy blobot áthelyeznek a ritka elérésű szintre, majd 21 nap után törölnek, a rendszer a blob ritka elérésű rétegben való tárolásának 9 (30 mínusz 21) napjával egyenértékű korai törlési díjat számít fel. A korai törlési díjak akkor is felmerülnek, ha a teljes objektumot bármilyen művelet (például Blob elhelyezése, Blokklista elhelyezése vagy Blob másolása) írják át a megadott időkereten belül. Ez a díj a megfelelő szint adattárolási ára alapján történik, azaz egy archivált blob 120 nap után történő törlése 180 napig fogja terhelni ezt az objektumot.

Feljegyzés

A helyreállítható törlést engedélyező fiókokban a blobok törlés után töröltnek minősülnek, és a megőrzési idő lejár. Amíg ez az időszak le nem jár, a blob csak ideiglenesen törölt marad, és nem vonatkozik a korai törlési büntetés.

A forró, a hűvös és a hideg szintek támogatják az összes redundanciakonfigurációt. Az Azure Storage adatredundancia-beállításairól további információt az Azure Storage redundanciájában talál.

Archív tárolási szint

Az archív szint egy offline szint, amely ritkán elérhető adatok tárolására használható. Az archív hozzáférési szint a legalacsonyabb tárolási költséggel rendelkezik. Ez a szint azonban magasabb adatlekérési költségekkel rendelkezik, és nagyobb késéssel rendelkezik a gyakori, a ritka elérésű és a ritka elérésű szintekhez képest. Az archív hozzáférési szint használati forgatókönyvei például a következők:

  • Hosszú távú biztonsági mentések, másodlagos biztonsági mentések és archiválási adatkészletek
  • Eredeti (nyers) adatok, amelyeket meg kell őrizni, még a végleges használható formában történő feldolgozás után is
  • Megfelelőségi és archiválási adatok, amelyeket hosszú ideig kell tárolni, és alig érhetők el

Ha meg szeretné tudni, hogyan helyezhet át egy blobot az archív szintre, olvassa el a blobok archiválása című témakört.

Az adatoknak legalább 180 napig kell az archív szinten maradniuk, ellenkező esetben korai törlési díjat kell fizetni. Ha például egy blobot áthelyeznek az archív szintre, majd 45 nap elteltével törlik vagy áthelyezik a gyakori rétegbe, a rendszer a blob archiválási szinten való tárolásának 135 (180 mínusz 45) napjával egyenértékű korai törlési díjat számít fel.

Feljegyzés

A helyreállítható törlést engedélyező fiókokban a blobok törlés után töröltnek minősülnek, és a megőrzési idő lejár. Amíg ez az időszak el nem jár, a blob csak puha törlés alatt van, és a korai törlésért fizetendő büntetés nem vonatkozik rá.

Bár egy blob az archív szinten van, nem olvasható és nem módosítható. Ha egy blobot az archív szinten szeretne olvasni vagy letölteni, először rehidratálnia kell azt egy online szintre, akár gyakori, akár ritka elérésű, akár hideg. Az archív szinten lévő adatok rehidratálása akár 15 órát is igénybe vehet a rehidratálási művelethez megadott prioritástól függően. A blobrehidratálással kapcsolatos további információkért lásd az archív réteg blobrehidratálásának áttekintését.

Az archivált blob metaadatai továbbra is elérhetők maradnak az olvasási hozzáféréshez, így listázhatja a blobot és annak tulajdonságait, metaadatait és indexcímkéit. Az archív szinten lévő blobok metaadatai írásvédettek, míg a blobindex-címkék olvashatók vagy írhatók. Az archivált blobok metaadatainak tárolási költségeit a hűvös réteg tarifái alapján számítják fel. Az archivált blobok nem támogatják a pillanatképeket.

Az archív szinten lévő blobok esetében a következő műveletek támogatottak:

Csak az LRS-hez, GRS-hez vagy RA-GRS-hez konfigurált tárfiókok támogatják a blobok áthelyezését az archív szintre. Az archív réteg nem támogatott ZRS-, GZRS- vagy RA-GZRS-fiókok esetében. További információ az Azure Storage redundanciakonfigurációiról: Azure Storage-redundancia.

Az archív szinten blobokat tartalmazó tárfiók redundanciakonfigurációjának módosításához először az összes archivált blobot a gyakori, ritka elérésű vagy hideg szintre kell rehidratálnia. Mivel a rehidratálási műveletek költségesek és időigényesek lehetnek, a Microsoft azt javasolja, hogy kerülje az archivált blobokat tartalmazó tárfiók redundanciakonfigurációjának módosítását.

A tárfiók LRS-ről GRS-re történő migrálása akkor támogatott, ha nem helyezték át a blobokat az archív szintre, amíg a fiók az LRS-hez lett konfigurálva. A fiók visszahelyezhető a GRS-be, ha a frissítést kevesebb mint 14 nappal a fiók LRS-vé való váltása után hajtják végre, és a fiók LRS-hez való beállításakor nem helyezték át a blobokat az archív szintre.

Alapértelmezett fiókhozzáférésszint-beállítás

A tárfiókok alapértelmezett hozzáférésiszint-beállítással rendelkeznek, amely azt az online szintet jelzi, amelyben új blob jön létre. Az alapértelmezett hozzáférési réteg beállítása lehet forró, hűvös vagy hideg. A felhasználók felülbírálhatják az egyes blobok alapértelmezett beállítását a blob feltöltésekor vagy a réteg módosításakor.

Egy új általános célú v2-tárfiók alapértelmezett hozzáférési szintje alapértelmezés szerint a gyakori elérésű rétegre van állítva. A tárfiók létrehozásakor vagy létrehozása után módosíthatja az alapértelmezett hozzáférési szintet. Ha nem módosítja ezt a beállítást a tárfiókban, vagy explicit módon állítja be a réteget egy blob feltöltésekor, akkor alapértelmezés szerint egy új blob lesz feltöltve a gyakori elérésű szintre.

A kifejezetten hozzárendelt szinttel nem rendelkező blobok az alapértelmezett fiókelérési szint beállításából következtetnek a rétegre. Ha egy blob hozzáférési szintje az alapértelmezett fiókelérési szint beállításából származik, akkor az Azure Portal a hozzáférési szintet Gyakori (kikövetkeztetett), Ritka (kikövetkeztetett) vagy Hideg (kikövetkeztetett) értékként jeleníti meg.

A tárfiók alapértelmezett hozzáférési szintjének módosítása a fiók összes olyan blobjára vonatkozik, amelyhez a hozzáférési szint nincs explicit módon beállítva. Ha a v2-es általános célú fiók alapértelmezett hozzáférési szint beállítását hidegebb szintre állítja, akkor fizetnie kell az összes olyan blob írási műveleteiért (10 000 műveletenként), amelynél a hozzáférési szint kikövetkeztetett. Az olvasási műveletekért (10 000-enként) és az adatlekérésért (GB-onként) egyaránt díjat számítunk fel, ha egy általános célú v2-fiók melegebb rétegére vált.

Régi Blob Storage-fiók létrehozásakor a létrehozáskor meg kell adnia az alapértelmezett hozzáférési szint beállítását gyakori vagy ritka elérésűként. Az alapértelmezett fiókhozzáférési szint beállításának egy régebbi Blob Storage-fiókban lévő, hűvösebb szintre történő módosításáért nem jár díj. Az olvasási műveletekért (10 000-enként) és az adatlekérésért (GB-onként) egyaránt díjat számítunk fel, ha egy Blob Storage-fiók melegebb rétegére vált. A Microsoft a Blob Storage-fiókok helyett általános célú v2-tárfiókok használatát javasolja, ha lehetséges.

Feljegyzés

Az archív szint nem támogatott a tárfiókok alapértelmezett hozzáférési szintjeként.

Blobszint beállítása vagy módosítása

Ha explicit módon szeretné beállítani egy blob szintjét a létrehozáskor, adja meg a réteget a blob feltöltésekor.

A blob létrehozása után a rétegét az alábbi módokon módosíthatja:

  • A Blob réteg beállítása művelet meghívásával közvetlenül vagy az életciklus-kezelési szabályzat segítségével. A Blobszint beállítása általában akkor a legjobb megoldás, ha egy blobszintet melegebbről hűvösebbre módosít.

    Feljegyzés

    Az archivált blobokat nem lehet online szintre rehidratálni életciklus-kezelési szabályzatok használatával.

  • Az Blob másolása művelet meghívásával másolhat egy blobot az egyik rétegből a másikba. A Copy Blob használatát a legtöbb olyan esetben ajánlott, amikor egy blobot az archív szintről egy online szintre rehidratál, vagy egy blobot a ritka elérésű vagy az archív szintről a gyakori elérésű szintre helyez át. Blob másolásával elkerülheti a korai törlési büntetést, ha a forrásblobhoz szükséges tárolási időköz még nem telt el. A blobok másolása azonban két blob, a forrásblob és a célblob kapacitására vonatkozó díjakat eredményez.

A blob rétegének módosítása melegebb rétegről hidegebbre vagy hűvösre, illetve hideg vagy hűvös rétegről forróra azonnali. Egy blob újrahidratálása az archív szintről egy online szintre, például a forró, a hűvös vagy a hideg szintre akár 15 órát is igénybe vehet.

A blobszint módosításakor tartsa szem előtt az alábbi pontokat:

  • A Blobszint beállítása nem használható titkosítási hatókört használó blob archiválására. A blobszint beállítása csak az online hozzáférési szintek közötti váltáshoz használható. A titkosítási hatókörökről további információt a Blob Storage titkosítási hatókörei című témakörben talál.

  • Ha egy blobot kifejezetten a hűvös vagy hideg szintre helyeznek át, majd az archív szintre, a korai törlési díj érvényes.

Blobéletciklus-kezelés

A Blob Storage életciklus-kezelése egy szabályalapú szabályzatot kínál, amellyel a megadott feltételek teljesülése esetén az adatok áttérhetnek a kívánt hozzáférési szintre. Az életciklus-kezeléssel az adatok az élettartamuk végén is lejárhatnak. További információ: Költségek optimalizálása az Azure Blob Storage hozzáférési szintjeinek automatizálásával.

Az archivált blobokat nem lehet online szintre rehidratálni életciklus-kezelési szabályzatok használatával. A prémium blokkblobtárfiókban tárolt adatok nem rétegezhetők forró, hűtött, hideg vagy archiválási szintre a Blob szint beállítása vagy az Azure Blob Storage életciklus-kezelésének használatával. Az adatok áthelyezéséhez szinkron módon át kell másolnia a blobokat a blokktárfiókból egy másik fiók értékes rétegére a Put Block From URL API-val vagy az AzCopy ezen API-t támogató verziójával. A Put Block From URL API szinkron módon másolja az adatokat a kiszolgálón, ami azt jelenti, hogy a hívás csak akkor fejeződik be, ha az összes adat az eredeti kiszolgáló helyről a célhelyre kerül.

Tárolási műveletek

Bár az életciklus-kezelés segítségével egy fiókon belül különböző szintek között helyezheti át az adatokat, tárolási feladatokkal ezt a feladatot több fiókra kiterjedő skálán hajthatja végre. A tárolási feladat az Azure Storage Actionsben elérhető erőforrás; egy kiszolgáló nélküli keretrendszer, amellyel több tárfiókban több millió objektumon hajthat végre gyakori adatműveleteket. További információ: Mi az Azure Storage Actions?

A hozzáférési szint beállításainak összegzése

Az alábbi táblázat a gyakori, ritka elérésű, hideg és archív hozzáférési szintek funkcióit foglalja össze.

Gyors elérésű réteg Ritka elérésű szint Hideg réteg Archív szint
Elérhetőség 99,9% 99% 99% 99%
Elérhetőség
(RA-GRS olvas)		 99,99% 99,9% 99,9% 99,9%
Használati díjak Magasabb tárolási költségek, de alacsonyabb hozzáférési és tranzakciós költségek Alacsonyabb tárolási költségek, de magasabb hozzáférési és tranzakciós költségek Alacsonyabb tárolási költségek, de magasabb hozzáférési és tranzakciós költségek Legalacsonyabb tárolási költségek, de a legmagasabb hozzáférés és tranzakciós költségek
Minimális ajánlott adatmegőrzési időszak n/a 30 nap1 90 nap1 180 nap
Késleltetés
(Az első bájtig eltelt idő)		 Ezredmásodperc Ezredmásodperc Ezredmásodperc Óra2
Támogatott redundanciakonfigurációk Minden Minden Minden Csak LRS, GRS és RA-GRS3

Az általános célú v2-fiókok ritka elérésű rétegében lévő objektumok minimális megőrzési időtartama 30 nap. Az általános célú v2-fiókok hideg rétegében lévő objektumok minimális megőrzési időtartama 90 nap. Blob Storage-fiókok esetén nincs minimális megőrzési időtartam a hűvös vagy a hideg szinten.

2 Amikor egy blobot az archív rétegből rehidratál, két beállítás között választhat: standard vagy magas rehidratálási prioritással. Mindegyik különböző lekérési késéseket és költségeket kínál. További információ: A blob rehidratációjának áttekintése az archív rétegből.

3 További információ az Azure Storage redundanciakonfigurációiról: Azure Storage-redundancia.

Árképzés és számlázás

Minden tárfiók egy blobszinten alapuló blokkblobtároló díjszabási modelljét használja. Vegye figyelembe a következő szakaszokban ismertetett számlázási szempontokat.

A blokkblobok díjszabásáról további információt a Blokkblobok díjszabása című témakörben talál.

Tárolási kapacitás költségei

A tárolt adatok mennyisége mellett az adatok tárolási költsége a hozzáférési szinttől függően változik. A gigabájtonkénti kapacitásköltség csökken, ahogy a réteg egyre hűvösebb lesz.

Adathozzáférési költségek

Az adathozzáférési díjak növekednek, ahogy a szint hidegebbé válik. A ritka gyakoriságú, hideg és archív hozzáférési szinten lévő adatok esetén gigabájtonkénti adathozzáférési díjat kell fizetnie az olvasásokért.

Tranzakciós költségek

A tranzakciónkénti díj az összes rétegre vonatkozik, és növekszik, ahogy a réteg egyre hűvösebb lesz.

Georeplikációs adatátviteli költségek

Ez a díj csak a georeplikációs konfigurált fiókokra vonatkozik, beleértve a GRS-t, az RA-GRS-t és a GZRS-t. A georeplikációs adatátvitel gigabájtonkénti díj ellenében érhető el.

Kimenő adatátvitel költségei

A kimenő adatátvitelek (az Azure-régióból átvitt adatok) gigabájtonkénti sávszélesség-használat számlázását vonják maga után. A kimenő adatátviteli díjakról további információt a Sávszélesség díjszabásának részletei oldalon talál.

Az alapértelmezett fiókelérési szint módosítása

A fiókhozzáférés szintjének módosítása rétegmódosítási díjakat eredményez minden olyan blob esetében, amely még nem rendelkezik explicit módon beállított szinttel. További információ: A blob hozzáférési szintjének módosítása című szakasz.

Blob hozzáférési szintjének módosítása

Tartsa szem előtt a blobszint módosításakor a következő számlázási hatásokat:

  • Amikor egy blobot feltöltenek vagy áthelyeznek a rétegek között, a feltöltés vagy a szint módosítása után azonnal a megfelelő díjért kell fizetni.
  • Ha egy blobot egy hűvösebb rétegbe helyez át, a művelet írási műveletként kerül számlázásra a célszintre, ahol az írási művelet (10 000-enként) és a célszint adatírási (GB-onkénti) díjai érvényesek.
  • Amikor egy blobot melegebb szintre helyeznek át, a rendszer a műveletet olvasásként számlázja ki a forrásszintről, ahol az olvasási művelet (10 000-enként) és a forrásszint adatlekérési (GB-onkénti) díjai érvényesek. A hűvös, hideg vagy archív rétegből áthelyezett blobok korai törlés díjai is felszámításra kerülhetnek.
  • Bár egy blob az archív szintből van rehidratálva, annak adatai archivált adatokként kerülnek kiszámlázásra mindaddig, amíg az adatok helyre nem állnak, és a blob szintje gyakori, mérsékelt vagy hideg elérésűre nem változik.

Az alábbi táblázat a rétegmódosítások számlázásának módját foglalja össze.

Díjak felszámítása (művelet + hozzáférés) Olvasási díjak (művelet + hozzáférés)
Forróról hűvösre
Meleg és hideg
Gyakori elérésű archiválás
Hűvös és hideg
Jó archiválni
Hideg az archiváláshoz		 Archiválás hideg tárolóba
Archiválás hűtésre
Archiválás gyakori elérésűre
Hidegtől hűvösig
Hideg és meleg
Hűvöstől forróig

Ha a verziószámozás engedélyezve van, vagy ha a blob rendelkezik pillanatképekkel, a blob hozzáférési szintjének módosítása további díjakat vonhat maga után. A verziókezelést engedélyező blobokkal kapcsolatos információkat a blob verziókezelési dokumentációjának Árazási és számlázási részében találja. A pillanatképeket tartalmazó blobokról további információt a blob pillanatképek dokumentációjában található díjszabás és számlázás című témakörben talál.

Hideg réteg

A hideg réteghez a REST, az SDK-k és az eszközök alábbi minimális verziói szükségesek

Környezet Minimális verzió
REST API 2021-21-02
.NET 12.15.0
Java 12.21.0
Python 12.15.0
JavaScript 12.13.0
PowerShell (Az.Storage) 5.8.0
Azure CLI 2.50.0
AzCopy 10.18.1
Azure Storage Explorer 1.29.0

Funkciók támogatása

Ennek a funkciónak a támogatását befolyásolhatja a Data Lake Storage Gen2, a Network File System (NFS) 3.0 protokoll vagy az SSH File Transfer Protocol (SFTP) engedélyezése. Ha engedélyezte bármelyik funkciót, tekintse meg a Blob Storage szolgáltatástámogatását az Azure Storage-fiókokban a funkció támogatásának felméréséhez.

Következő lépések