Blobadatok hozzáférési szintjei
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 nagyon ritka elérésű hozzáférési szintnek a ritka elérésű szinthez képest alacsonyabbak a tárolási és magasabbak az elérési költségei.
- 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 tárolják (akár gyakori, akár ritka elérésű), 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. A ritka vagy a ritka elérésű szint ideális a ritkábban elérhető adatokhoz, de ennek 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 a későbbiekben a ritka hozzáférési szintre való áttelepítésre előkészített adatok.
A ritka elérésű és a 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 ritka elérésű és a ritka elérésű 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 gyakori elérésű réteg. A ritka elérésű vagy hideg rétegben lévő adatok esetében a rendelkezésre állás és a magasabb hozzáférési költségek elfogadható kompromisszumot jelenthetnek a gyakori elérésű szinthez képest alacsonyabb általános tárolási költségek esetén. 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 ritka elérésű rétegében lévő blobra korai törlési büntetés vonatkozik, ha 30 nap elteltével törölték vagy áthelyezték egy másik szintre. A hideg rétegben lévő blobok esetében a törlési büntetés akkor érvényes, ha 90 nap elteltével törölték vagy áthelyezték 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.
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 helyreállíthatóan törölve lesz, és nem vonatkozik a korai törlési büntetésre.
A gyakori, ritka elérésű és 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 helyreállíthatóan törölve lesz, és nem vonatkozik a korai törlési büntetésre.
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 rendszer ritka elérésű tarifacsomagok alapján számítja 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:
- Blob másolása
- Blob törlése
- Blobok leválasztás
- Blobok keresése címkék szerint
- Blob-metaadatok lekérése
- Get Blob Properties
- Blobcímkék lekérése
- Blobok listázása
- Blobcímkék beállítása
- Set Blob Tier
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 30 nappal a fiók LRS-vé való váltásától számított 30 napon belül 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 szint beállítása lehet gyakori vagy ritka elérésű. 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 elérésű (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 az alapértelmezett hozzáférési szint beállítását egy általános célú v2-fiók egy hűvösebb rétegére állítja, akkor az írási műveletekért (10 000-re) kell fizetnie az összes olyan blob esetében, amelyre 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 Blobréteg beállítása művelet meghívásával közvetlenül vagy életciklus-kezelési szabályzattal. 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.
A Blob másolása művelet meghívásával másolja a blobokat az egyik rétegből a másikba. A Másolási blob meghívása a legtöbb olyan esetben ajánlott, amikor egy blobot az archív szintről online szintre rehidratál, vagy egy blobot a ritka vagy a ritka elérésűről a gyakori elérésűre 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 blobok rétegének melegebb rétegről hidegebbre történő módosítása azonnali, ahogy a hideg vagy a ritka elérésűről a melegre változik. Egy blob újrahidratálása az archív szintről egy online szintre, például a gyakori, a ritka elérésű vagy a hideg rétegre akár 15 órát is igénybe vehet.
A blobszint módosításakor tartsa szem előtt az alábbi pontokat:
- Titkosítási hatókört használó blobon nem hívhatja meg a Blobszint beállítása lehetőséget. 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 ritka vagy a ritka elérésű szintre helyeznek át, majd az archív szintre helyezik át, 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 szintű blokkblobtárfiókban tárolt adatok nem rétegezhetők gyakori, ritka elérésű, ritka elérésű vagy archiválási szintre a blobszint 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 blokkblobtárfiókból egy másik fiók gyakori rétegére a Tiltás tiltása URL-címből 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 egyetlen fiók rétegei között helyezheti át az adatokat, a tárolási feladatokkal ezt a feladatot több fiókra kiterjedő skálázható skálázva 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.
| Gyakori 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ások) |
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ésés (Az első bájtig eltelt idő) |
Ezredmásodperc | Ezredmásodperc | Ezredmásodperc | Óra2 |
| Támogatott redundanciakonfigurációk | Mind | Mind | Mind | 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 ritka vagy a ritka elérésű szinten.
2 Amikor egy blobot az archív rétegből rehidratál, választhat egy standard vagy egy magas rehidratálási prioritású beállítást. 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 egyre magasabbak lesznek. A ritka elérésű, ritka elérésű és archív hozzáférési szinten lévő adatokért 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 ritka elérésű, hideg vagy archív rétegből áthelyezett blobok korai törlési díjai is érvényesek lehetnek.
- Bár a blobok rehidratálva vannak az archív rétegből, a blob adatai archivált adatokként lesznek kiszámlázva, amíg az adatok vissza nem állíthatók, és a blob szintje gyakori, ritka elérésű vagy ritka elérésűre 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 írása (művelet + hozzáférés) | Olvasási díjak (művelet + hozzáférés) |
|---|---|
| Gyakori elérésű és ritka elérésű Meleg és hideg Gyakori elérésű archiválás Hideg és hideg Ritka elérésű archiválás Hideg az archiváláshoz |
Archív a hideg Archiválás a ritka elérésűre Archiválás gyakori elérésűre Hideg és hideg Hideg és meleg Ritka elérésű |
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ószámozást engedélyező blobokról további információt a blob verziószámozási dokumentációjában talál. 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 |
Szolgáltatások 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.