Schema-less service indexes data automatically for fast queries
SLA for 99,999% availability
Data Replication between Azure Regions is automatic
Data protected with encryption-at-rest and role-based access
Autoscale is provided to handle various workload sizes
Cosmos DB APIs
Different types of APIs to support wider range of applications
Core SQL API
enables querying with language similar to SQL
Azure Table API
used to communicate with Azure Table Storages
allows indexes in the partition and row keys
MongoDB API
Cassandra API
using Cassandra Query Language
Gremlin API
graph-based
Core Components
Database
logical namespace for collections, users and permissions
Container - a unit of compute
Collection - maps to a container, is billable entity, cost is determined by the provisioned throughput expressed in request per second (RPS)
Cosmos DB Explorer
Web interface to explore and interact with your Cosmos DB accounts
Can create new dbs and containers
uses CosmosDB Core SQL
Azure Portal > Azure Cosmos DB > Data Explorer
Also use Gremlin
Partitioning Schemas in Cosmos DB
data among partitions indexes is grouped by the partition keys in order to improve performance
Main concepts of Partitioning Schemas
Partition Keys - works like primary keys
Logical Partition - have the same partition key value
Physical Partitions consists of a set of logical partitions Azure Cosmos DB manages logical partitions which can have one to many
Replica Sets - Group of Physical Partitions - materialized as self-managed, dynamically load-balanced group of replicas that span across multiple fault domains
Choosing a partition key
Two components
partition key path - '/userId' - accepts alphanumeric and underscore characters. also use nested objects by using standard path notation(/)
partition key value - ‘Andrew’ - can be of type string or numeric
Partition keys for ALL containers should be:
a property that will not change in value
You can’t change the value of a property that is your partition key
Should be able to have a wide variety of values GUID
Spread request unit (RU) consumption and data storage evenly accross all logical partitions
Ensures even RU consumption and storage distribution across your physical partitions
Choosing a unique key
allows developers to add a layer of data integrity to their database
ensure uniqueness of one or more values per partition key
unique key is scoped to a logical partition /first_name, /adress/zip
Can’t update an existing container to use different unique key (forethought required)
Can have a maximum of 16 path values
Each unique key policy can have a maximum of 10 unique key constraint or combination.
When container has a unique key policy, RU charges to create, update and delete an items are slightly higher
Unique keys are case-sensitive
Containers
Azure Cosmos Containers are useful for scalability , both in terms of storage and throughput
Properties
System-defined - normally has underscore in front of it _rid
user-configurable
examples:
_
Capacity
defines underlying resources available for you to use (support consumption)
Two capacity modes
Provisioned throughput
provision amount of RU per second
when you can predict traffic
more flexible options
sense at scale
Serverless
low workloads
unpredictable spike and traffic
easy to configure with limitations
sense at start
Database-Level Shared throughput
Two different throughput strategies
Dedicated mode - exclusive throughput to this container backed by SLA
Shared mode - throughput shared across all containers
Shared throughput is not available for Capacity Mode or Serverless
Reading Data
Point Reads
key/value lookup on a single item id
1 RU
1 item returned
Required to include partition key
Queries
allows to return multiple items
at least 2.3 RUs
unlimited items returned
Recommended to include partition key
Request Units (RUs)
Cost of database operations are normalized by Azure Cosmos DB and expressed by Request Units
Abstracts away Memory, CPU and IOPS with single value based on data processed
DB Operations:
Read - 1kb = 1RU, 100kb = 10RUs
Insert - 1kb without indexing around 5.5RUs
Upsert - replacing an item costs double the charge required to insert same item
Delete
Query - size of the items retrieved
Calculating capacity can be confusing to do manually, use Capacity Calculator cosmos.azure.com/capacitycalculator
Consistency Levels
Five different consistency levels to maintain data availability and querying performance
Strong -
Bounded Staleness -
Session -
Consistent Prefix
Eventual -
Strong Consistency
Read operations ensure most recent data is returned
Read operations cost the same as Bounded Staleness but more than session and eventual consistencies
Write operations can only be read after data has been replicated by most replicas
Bounded Staleness
Read operation are lagged behind writes due to time or version differences
Read operations costs teh same as Strong Consistency and more than session and eventual consistency
Highest level of consistency compared to session, consistent-prefix and eventual consistancy
Recommended for globally distributed applications with high availability and low latency.
Session
Read operations ensure written data is consistent within same session
Consistancy is scoped to a user session, other users may have ‘dirty’ data if a user has just written it.
Default for newly created databases
Reading cost is lower than Strong and Bounded Staleness but higher than eventual consistency.
Consistent Prefix
Read operations ensures that the most recent data replicated among replicas is returned, does not guarantee that the data is most recent
Dirty data occurs when one replica changes the data state but this data has not yet been replicated
Stronger consistency level than eventual consistency but less than others
Eventual
Read operations does not guarentee any consistency level
Lowest consistency level
Lowest latency and best performance
Least expensive read operations compared to any other consistency level
Change Feed
Azure Cosmos DB service that monitors changes in all containers and distributes events triggered by those changes to multiple consumers
Is a persistent record of changes to a container in the order they occur.
SDK for .Net, Java, Python and NodeJS
Supported for SQL API, Cassandra API, MongoDB API, Gremlin API
Change Feed is not supported for Table API
Change Feed Process Library
Composed of four components
Monitor container - Where the insert and update executes
Lease container - stores the states and coordinates the change feed processor
The host - application instance that uses change feed processor to listen for changes
The delegate - the code that runs when any event in the changes feed notifications triggers it.
Change feed processor can be hosted among Azure services that support long-running tasks