Skip to content

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