Azure Databases
- Azure SQL
- Third party - MySQL, Maria DB, PostresSQL etc
- NoSQL: Cosmos DB
Azure SQL
- Single DB - single database with defined resources
- Elastic Pool - multiple databases sharing resources across a pool
- Managed Instance - Most compatible with on-prem SQL Server, but managed by Azure
- Serverless?
- Pricing tiers:
- vCore: corresponds to CPU core, allows fine-grained choice of CPUs and disk space
- DTU: Database Transaction Units cheaper, fewer customizations
- Data Migration
- Azure Data Migration Service: establish a connection to on-prem
- Data Migration Assistant: simpler option, allows selecting schema, optionally data, to be migrated
- Security
- at-rest data encryption
- Dynamic Data Masking DDM to protect sensitive, PII data
CosmosDB
- API compatibility with: Azure tables, Cassandra, MongoDB, etcd and Gremlin
- Core (SQL) is recommended for the new applications
- Hierarchy: Account > Database > Container > Item
- Account has a globally unique resource name
- throughput can be provisioned at Database or Container levels
- Items are JSON documents
- data is sharded into logical partitions using partitioning key
- logical partitions are mapped to physical partitions by Azure based on performance requirements
- each physical partition writes to 3 replicas known as replica set
- data can be replicated across regions and geo
- allows writes to any replica to be replicated, or write-one-read-many (write only to primary region)
- number of regions for replication can be changed after the database has been created
- provisioned and priced by Request Unit RU per second
- e.g. write simple document: 5 RU, simple query: 50 RU
- Indexing is by default and indexes all fields
- inverted index can search across documents even with different schemas
- default can be overridden by specifying
- include.json : paths to include for indexes, attributes: data type, kind (range/hash/spatial), precision
- exclude.json : processed after include paths
- consistency levels are selectable
- strong: all replicas are written for write to complete
- bounded staleness: maximum time write can be inconsistent
- session: consistency guaranteed in the context of the user's session, everyone else has eventual
- eventual: all writes are eventual