Describe Considerations for Working with Non-Relational Data on Azure
Azure Cosmos DB
Cosmos DB is a globally distributed, multi-model NoSQL service. Know its APIs: NoSQL (document), MongoDB, Cassandra (column-family), Gremlin (graph), and Table. Data is partitioned by a partition key you choose at creation; a good key spreads traffic evenly and is used in most queries. Throughput is expressed in request units (RU/s).
Memorize the five consistency levels from strongest to weakest: strong, bounded staleness, session, consistent prefix, eventual. Session is the default and satisfies read-your-own-writes within a session; eventual offers lowest latency.
Azure Storage data services
- Blob storage for unstructured objects: block blobs (files, media, backups), page blobs (random reads/writes, used for VHDs), append blobs (logs). Access tiers: hot, cool, cold, archive; archive is cheapest for storage but requires rehydration (hours) before reading.
- Azure Files for managed SMB/NFS file shares.
- Queue storage for asynchronous messages.
- Table storage for key-value/NoSQL entities at low cost.
Redundancy: LRS (single region), ZRS (zones in one region), GRS/RA-GRS (replicated to a secondary region; RA adds read access).
Traps and a rule of thumb
Traps: assuming Cosmos DB Table API and Azure Table storage are the same product (Cosmos adds global distribution, SLAs, and lower latency); picking archive tier for data read daily; choosing eventual consistency when the app must read its own writes.
Rule of thumb: unstructured files go to Blob; relationship-heavy graphs go to Cosmos DB Gremlin; if the app must read what it just wrote, use session consistency.