LRS - LOCALLY Redundant Storage (1n i Data Centre)
====================================
ZRS - Zone Redundant Storage (Across Zones)
======================================
GRS - Geo Redundant Storage (Acrosss Regions)
Paired Regions
=================================================================
Primary I create
Secondary , Not accessible, by user, But used by Azure themselves
=================================================================
LRS is by default Always ON
=================================================================
Replication vs Backup
Replication in Synchronous
it will give me 200 HTTP only when it saves on Secondary as well
Region Replication is Asynchronous
=================================================================
listing is allowed in CONTAINER, but not in BLOB Public Access
https://docs.microsoft.com/en-us/rest/api/storageservices/list-blobs
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list
=================================================================
SAS not based on SAP - can't be revoked:
If you are using ad hoc URIs, you have three options. You can issue SAS tokens with short expiration policies and wait for the SAS to expire. You can rename or delete the resource (assuming the token was scoped to a single object). You can change the storage account keys. This last option can have a significant impact, depending on how many services are using that storage account, and probably isn't something you want to do without some planning.
SAS based on SAP - can be revoked by revoking SAP:
If you are using a SAS derived from a Stored Access Policy, you can remove access by revoking the Stored Access Policy – you can just change it so it has already expired, or you can remove it altogether. This takes effect immediately, and invalidates every SAS created using that Stored Access Policy. Updating or removing the Stored Access Policy may impact people accessing that specific container, file share, table, or queue via SAS, but if the clients are written so they request a new SAS when the old one becomes invalid, this will work fine.
Best practice:
Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.
================================================================
Access Tier
HOT Tier ---> Frequently Accessed
Cool Tier --> Infrequently Accessed
Archive --> Archival data (rarely accessed)
================================
Premium -> Always Frequently--> SSD Tier
================================
https://docs.microsoft.com/en-us/azure/storage/blobs/soft-delete-blob-overview
========================================================
COSMOS DB ???
https://volosoft.com/blog/Introduction-to-Azure-Cosmos-DB
Azure Cosmos DB supports 5 type of APIs.
- SQL API (Json)
- MongoDB API (Bson)
- Gremlin API (Graph)
- Table API (Key-Value)
- Cassandra API (columnar)
========================================================
Consistency
Replication comes with a choice of consistency. So, when one instance of your app writes data to a write-region, Azure needs to replicate this data to other regions.
Azure Cosmos DB offers 5 type of consistency levels. It means, you need to select how Azure should replicate your data between your Azure Cosmos DB regions. Let’s see what are those consistency levels:
Strong
In this model, there are no dirty reads. It means, when a data is updated, everybody will read the old value until the data is replicated to all regions. This is the slowest option.
Bounded Staleness
In this option, you can define period of time or update count for the staleness of your data. You can say that, no dirty reads for 1 minute or no dirty reads for data updated more than 5 times. When you set the time option to 0, it will be exactly same as Strong consistency option.
Session
In this option, no dirty reads are possible for writers but dirty reads are possible for readers. This is the default option. So, if you are the one writing the data, you can read that data. But for others, they can read stale data for a while.
Consistent Prefix
In this option dirt-reads are possible but they are always on order. So, if a data is updated with the values 1,2,3 in order, readers always see the updated data in this order. No one will see the value 3 before 2.
Eventual
In this option, dirty reads are possible and there is no guarantee of order. So, if a data is updated with the values 1,2,3 in order, a reader can see value 3 before seeing value 2. But, this is the fastest option.
Here is a commonly used image for showing consistency options of Azure Cosmos DB:
No comments:
Post a Comment