1. Developing Cosmos DB for the Enterprise
Will Velida
Developing Cosmos DB for the Enterprise

2. About Me Graduate Software Engineer for ASB Bank.
Not actually a Kiwi 
.NET and Azure
@willvelida
Medium
LinkedIn
My name is Will Velida, I’m a Graduate Software Engineer working in the Payments team for ASB Bank.
Just a little on my background:
In case you haven’t guessed yet, I’m not actually a kiwi! I’m originally from the UK but I’ve been living in New Zealand for almost 9 years now.
At work, I spend most of my time doing stuff on .NET and Azure with a lot on Cosmos (hence the talk).

3. Agenda What is Azure Cosmos DB? Modelling our data
Working with Containers and Items
Distributing our data
Partitioning
Indexing Strategies
Provisioning Throughput
Monitoring Cosmos DB
Security
Backups
So we’ve got a lot to cover today. My aim is to help you all understand what you need to consider when developing Cosmos DB databases for production scenarios.
I’ll provide quick overview of what Cosmos DB is, but I’ve got a production checklist that my team have used when developing applications that I’ll keep to when discussing topics.
That covers topics such as data distribution, partitioning in Cosmos, Indexing strategies, throughput monitoring and security.
Hopefully I’ll cover enough today so you can get started developing and administrating Cosmos DB accounts for production scenarios,
If there’s time at the end, I’ll do a QnA so if you have questions, please leave them to the end and I’ll do my best to answer.

4. Thanks to our great Sponsors
Gold Sponsors
Silver Sponsors
Global Sponsors
Before I start, I just want to thank our sponsors for making SQL Saturday happen!
Bronze Sponsors

5. A brief overview of Cosmos DB
So let’s briefly go over what Cosmos DB is,’
How many of you know what Cosmos DB is?
How many of you use Cosmos DB in production?

6. What is Cosmos DB?
“A fully managed database service with turnkey global distribution and transparent multi-master replication”

7. Benefits Global Distribution Elastic Scalability
Guaranteed low latency
Defined Consistency choices
No schema or index management
Multiple data models to choose from
Azure Cosmos DB is a fully managed database with turnkey global distribution and multiple datamodels to choose from.
We can scale our Cosmos DB accounts throughput and storage across to any Azure region worldwide and take advantage of fast data access using a variety of different API’s such as SQL, MongoDB, Gremlin etc.
Cosmos enables us to build highly available and responsive applications that replicated data wherever our users are. We can also add and remove regions to our Azure account at any time.
Cosmos is elastically scalable in terms of throughput and storage with horizontal partitioning and multi-master replication
We have worldwide guaranteed low latency at the 99th percentile and we have multiple consistency levels to choose from, which is an advantage over NoSQL databases
The database engine itself is schema-agnostic, which means no schema or index management is required. Cosmos automatically indexes all of our data, which enables us to perform fast queries
Horizontal partitioning is a database design principle whereby rows of a database table are held separately, rather than being split into columns

8. Multiple API’s and Data Models
Atom Record Sequence
Document (SQL and MongoDB API’s)
Key-Value (Table API)
Graph (Gremlin API)
Columnar (Cassandra API)
Cosmos has different APIs that interact with different data models ,
We have Document data models for SQL (Core API) and Mongo DB API
Key-Value for Table API (which will eventually replace Azure Table Storage)
Graph data models for Gremlin API
Columnar for Cassandra API’s
Essentially all these apis interact with Atom Record Sequence (ARS) which is how our data is stored in Cosmos.
Currently, we can only create a Cosmos account that interacts with one API, but in the future, we’ll be able to switch freely between different APIs

9. Production Checklist
Top queries been determined for best partition key strategy
Top query filters for each container been added to the indexing policy
Throughput requirements calculated correctly
Diagnostic logging enabled
TTL requirements have been determined.
At ASB, we’ve been using a production checklist that Microsoft handed to us to get our Cosmos DB account ready for production scenarios and I’ll keep referring back to this as I go along.

10. Data Modelling in Cosmos DB
Before we tackle each aspect of the Production checklist, let’s take a look at how we model our data in Cosmos

11. Data Modelling for Schema-free?
Just because Cosmos is Schema-free, doesn’t mean we shouldn’t be concerned about data modelling
Data Modelling is important for our applications
We should spend time thinking about our data models
Before we even start to design our Cosmos DB applications, we should think about our data model that we’re going to use.
This will help us in terms of performance and scalability and lowest cost
How is data going to be stored? How is your application going to retrieve and query data? Is your application read-heavy, or write-heavy?

12. Embedding Data Contained relationship between entities.
One-to-few relationships between entities
Embedded data changes infrequently.
Will not grow without bound
Queried frequently together.
In relational databases, we would normalize our data and break it down into discrete properties in a attempt to avoid storing redundant data on each record. Such an approach would require write operations across many individual tables.
In Cosmos, it’s a good idea to contain our documents as much as possible when starting out
So in a normalized database, we would have separate tables for addresses, contact details etc, but here we have denormalized this by embedding these properties into a single JSON document.
Retrieving a person is a now a single read operation against a container and updating a person would also be a single write operation. Generally, denormalized data models provide better read performances.
When to use embedded data models: (slide points)
We wouldn’t embed our data if we have arrays in our documents that are unbounded (meaning that there is not limit to how many values an array has).
We also wouldn’t embed our data when it’s used across items and will change frequently.

13. Referencing Data Representing one-to-many relationships.
Representing many-to-many relationships.
Data changes frequently.
Data could be unbounded.
We can also create relationships between entities in document databases.
This is done by having information in one document that relates to data in other documents.
In Cosmos, it’s best that we keep these simple.
In this example, we have a reference to the stock documents in our Person document, but in this case the stock document will be the only one that changes.
However, if we had to display the number of stocks a person has, we’d need to make more trips to the database
Inter-document relationships are generally weak, so in order to verify that the link actually exists, we need to do this either in our application or through server-side logic through triggers and stored procs.
When to reference (slide point)

14. General advice on modelling
Data modelling in the schema-free world is more important than you think!
Need to understand how your application uses data
Schema-free databases are flexible enough to change (Can even do a mix of Embedded and Referenced data).
Just as there is no single way to represent a piece of data on a screen, there is no single way to model your data.
 need to understand your application and how it will produce, consume, and process the data

15. Provisioning Throughput

16. Request Units (RU’s) Currency for throughput.
Charged on an hourly basis.
When we perform operations in Cosmos, we spend RU’s.
When we provision throughput, we set the amount that we reserve for capacity.
When we make operations against our Cosmos Databases, we use something called Request Units (RU’s) which is what you use for throughput
If you’re writing an item to Cosmos, you spend RU’s. If you read an item in Cosmos, you’re spending RU’s. If you’re making a query in Cosmos, you get the idea.
This is consistent no matter what API you’re using for your Cosmos account.
With Azure Cosmos DB, you pay for the throughput you provision and the storage you consume on an hourly basis. Throughput must be provisioned to ensure that sufficient system resources are available for your Azure Cosmos database at all times. 

17. How can we estimate RU expenditure
Keep in mind:
Item size and Item Property count
Indexing on items and properties
Data consistency
Query complexity
Script usage
We should be aware of how big our items will be when designing them, The larger they are, the number of RU/s required to write and read them will increase. This is also the case for the number of properties our items has
Every item in Cosmos DB collections are indexed, along with every property. This does provide us with fast queries, but can be expensive in terms of Request Unit costs.
We can decrease this cost by limiting the number of indexed properties by defining our own indexing policies.
We can also set the indexing mode on our collections. Consistent, which is when the index is updated synchronously as we perform operations on items in Cosmos or None, which essentially disables indexing. This is helpful for bulk inserts.
The level of Data Consistency applied will also have an effect on RU expenditure, strong and bounded staleness consistency levels consume two times more request when performing read operations compared to other consistency levels.

18. Database vs Container Provisioning
When provisioned at a Database level, all containers share the throughput.
We can’t select which container gets what RU/s.
All containers must be created with a partition key.
When provisioned on a container, it’s reserved for that container.
Guaranteed performance for that container.
Throughput is distributed across all logical partitions.
When we provision throughput at a database level, all containers within that database will share the provisioned throughput. This is a cheaper way of provisioning throughput, but it comes at the expense of not receiving predictable performance on a specific container.
One reason we might want to provision throughput at the database level is that we have a few collections (less than 10) in our database and we want to save on costs.
When we provision throughput on a container, it’s reserved for that container (obviously). That means that container will receive that throughput all the time.

19. Containers and Items

20. Containers Unit of scalability for throughput and storage
Can scale elastically
Container for our items
SQL API
Cassandra API
MongoDB API
Gremlin API
Table API
Collection
Table
Graph
Containers are essentially what tables are in a relational database
Horizontially partitioned and then replicated across multiple regions
Items added to containers along with the throughput that we provision on it ae distributed across a set of logical partitions based on the partition key.
I’ll discuss how we can configure throughput on Databases and Collections later.
When we register server-side code such as Stored Procs, triggers etc. We register them on the container.

21. Items Essentially documents that sit within our containers.
We can perform the following operations on items:
Insert
Replace
Delete
Upsert
Read
SQL API
Cassandra API
MongoDB API
Gremlin API
Table API
Document
Row
Node or edge
Item
Items are essentially values within our containers. They have different terms across different APIs
Across all APIs we can perform the following operations on them.

22. Time to Live (TTL)
Automatically delete items from a container after a certain time period.
Can set TTL on either a container or item level.
Background task that consumes RU’s that haven’t been used for user requests.
We can set Time to Live on our items in Cosmos DB, which deletes our items automatically after a defined period of time (seconds)
We can set this either at a Container level or at an item level.
No delete operation is required by our clients, Cosmos will do this as a background task automatically.

23. Example TTL Configurations
Example 1: DefaultTimeToLive = null
TTL on Item
Result
TTL = null
Disabled. Item will never expire.
TTL = -1
TTL = 2000
Example 1: DefaultTimeToLive = -1
TTL on Item
Result
TTL = null
Enabled. Item will never expire
TTL = -1
TTL = 2000
Enabled. Item will expire after 2000 seconds
Let’s go over some example TTL configurations
If we don’t set Time to Live on a container (ie set it to null), then whatever ttl we set on an item won’t take effect
If we set the TTL to -1 (ie never expire the items on a container) then set the ttl on a specific item, then that item will expire after a configured amount of time and the remaining items in our container will not expire.
Essentially, in order for TTL to work, we need to enable it on a container level and then apply any TTL configurations that we need to on a item level.
To set TTL, we can do this either in the portal or using a supported SDK

24. Unique Key Constraints
Add integrity to our data through Unique Keys
We can make sure that one or more values within a logical partition is unique.
Define a unique key when creating a container.
Prevents duplicates when creating or updating items.
Unique keys add a layer of data integrity to an Azure Cosmos container. You create a unique key policy when you create an Azure Cosmos container. With unique keys, you make sure that one or more values within a logical partition is unique
After you create a container with a unique key policy, the creation of a new or an update of an existing item resulting in a duplicate within a logical partition is prevented, as specified by the unique key constraint.

25. Example TeamID FirstName LastName Email Valid Payments Will Velida Y
Customer
John
Smith N
Duplicate throws an error.

26. Transactions Support for ACID Transactions in Cosmos DB
Both for write and read operations
Transactions can be rolled back on exceptions
We can use transactions to deal with concurrent changes to the data.
In the SQL Server world, we use stored procedures to execute logic directly within the database engine.
With traditional relational databases, you are required to deal with two different programming languages the (non-transactional) application programming language such as JavaScript, Python, C#, Java, etc. and the transactional programming language (such as T-SQL) that is natively executed by the database.
Cosmos DB supports ACID transactions with snapshot isolation.
All operations on our database within our containers logical partition is excueted within the database engine that is hosted by the replica of the partition
When we write Server side logic, we do this using JavaScript.
Cosmos DB natively supports JavaScript execution inside the database engine
If an error is thrown during execution of our server side logic, the entire transaction is aborted and rolled back.

27. Concurrency Control
Every item stored in a container has a _etag property
This is generated every time the item is updated.
We can use this property to let the server decide whether or not an item should be updated.
This is achieved with the If-Match request header.
ETag Match
ETag Stale
If-Match
HTTP 412
Check ETag

28. Partitioning

29. Partitioning in Cosmos
In order to scale, Cosmos uses partitioning.
Items are divided into logical partitions which are based on partition keys.
For example. If we have a NewsStory container partitioned on news category and we have 10 unique values for a news category, there will be 10 logical partition for that story container.
you’ll need to understand how partitioning works to ensure that you don’t suffer from performance issues such as throttling.
By having an effective partitioning strategy, we can ensure that our Cosmos databases can meet the performance requirements of that our applications demand.
In order to scale containers within a database that meets the performance requirements that our applications needs, Cosmos DB uses partitioning. Items in our containers are divided into logical partitions which are based on partition keys that we associate with each item in a container.

30. Logical and Physical Partitions
Logical partitions are partitions that consist of a set of items that have the same partition key.
Physical partitions are partitions that our logical partitions map to.
This sits within a replica set and each replica set hosts an instance of the Cosmos DB Engine.
 So using our News Story container example, say if all our items have a “Category” property, we can use that as the partition key. Say if we have values for “Sport”, “Tech” and “Financial” categories, these group of items will form their own distinct logical partitions. If we need to delete the underlying data from a partition, we don’t need to delete the partition ourselves.

31. Picking a partition key
Vital for performance.
Requests made to partition keys can’t exceed to amount of throughput we have provisioned to the container or database
Need to pick a partition key that has a wide range of values.
This will help us balance workloads over time.
To avoid ‘hot partitions’ we need to pick a partition key that has a wide range of values that spread evenly across logical partitions. This ensures that throughput and storage are spread evenly across our logical partitions.
A good partition key would be a property that we frequently use as a filter in our Cosmos DB query.

32. Generating Synthetic Partition Keys
We can generate a synthetic partition key if properties in our documents don’t have many distinct values.
Concatenate multiple properties
Random Suffix
Pre-calculated suffixes
Sometimes our documents don’t have proper many distinct values for us to use as a partition key
If this is the case we have some basic strategies that we can use to create synthetic partition keys
We can concatenate multiple properties in our documents to create a artificial partition key,
We can apply a random suffix. This is helpful when performing parallel write operations across partitions, which improves throughput.
Or we can use a pre-calculated value. This is better when we need to read specific items in containers

33. Indexing Strategies

34. Indexing in Cosmos Every container has an indexing policy.
Allows for high query performance without having to think about it.
You may want to override this to suit your requirements.
In Azure Cosmos DB, every container has an indexing policy that dictates how the container's items should be indexed.
The default indexing policy for newly created containers indexes every property of every item, enforcing range indexes for any string or number, and spatial indexes for any GeoJSON object of type Point.
This allows you to get high query performance without having to think about indexing and index management upfront.

35. Types of Indexes Range Spatial Composite
Equality, Range, Order By, Joins
Spatial
Geospatial distance queries
Geospatial within queries
Composite
Order By on multiple properties
Currently, Cosmos DB supports 3 types of Indexes
Range
These are used on scalar (string or number) values
Spatial
These indexes are use on GeoJSON objects. Points, LineStrings and Polygons are supported
Composite
Queries that ORDER BY two or more properties require a composite index. Currently, composite indexes are only utilized by Multi ORDER BY queries. By default, no composite indexes are defined so you should add composite indexes as needed.

36. Indexing Modes Consistent:
Index updated as you create, update or delete items.
Consistency of read queries will be the consistency configured for the account
None:
Indexing is effectively disabled on the container
Good for key-value stores without the need for secondary indexes
Can help speed up bulk insert operations
Consistent: If a container's indexing policy is set to Consistent, the index is updated synchronously as you create, update or delete items. This means that the consistency of your read queries will be the consistency configured for the account.
None: If a container's indexing policy is set to None, indexing is effectively disabled on that container. This is commonly used when a container is used as a pure key-value store without the need for secondary indexes. It can also help speeding up bulk insert operations.

37. Property Paths Property Path Scalar /? Array /[] Wildcard /*
A custom indexing policy can specify property paths that are explicitly included or excluded from indexing.
By optimizing the number of paths that are indexed, you can lower the amount of storage used by your container and improve the latency of write operations.
When a path is explicitly included in the indexing policy, it also has to define which index types should be applied to that path and for each index type, the data type this index applies to:
Index typeAllowed target data typesRangeString or NumberSpatialPoint, LineString or Polygon
Word of warning: if you’re defining a custom indexing policy and applying it via a PowerShell task in DevOps

38. Modifying our Indexing Policies
.NET SDK Example
Azure CLI Example
The indexing policy is essentially just a JSON file.
We can create a custom indexing policy and then apply it to the container using either a supported SDK or the Azure CLI
The time that it takes for a new policy to take effect depends on the throughput provisioned on the container, number of items and the size.
However, if we perform queries on the container, it may not return all the matching results and it will not return errors, but our results will be inconsistent.

39. Distributing our data

40. Enabling Distribution
Consistency vs Availability, Latency and Throughput.
Most distributed databases make us choose between strong and eventual consistency.
Strong provides great data programmability.
Eventual offers high availability and better performance
When we use distributed databases, we usually have to make a tradeoff between read consistency vs availability, latency and throughput.
Cosmos DB approaches this a spectrum between the choices rather than an explicit choice between the two extremes.
This allows us as developers to make more granualar choices when it comes to high availability and performance.

41. Consistency Levels Strong Bounded Staleness Session Consistent Prefix
Eventual

42. Breakdown of levels Consistency Level Guarantees
Strong
Once operation is complete, visible to all
Bounded Staleness
Reads may lag behind writes either by the number of updates to an item or by time interval
Session
Within a client session, reads guaranteed to honor consistent prefix, monotonic reads and writes, read-your-writes and writes-follows-reads.
Consistent Prefix
Reads will never see out of order writes
Eventual
Potential for out of order reads

43. Figuring out the trade-off
Read and write latency for all consistency levels guaranteed to be less than 10ms.
Session, consistent prefix and eventual provide 2x read throughput compared to strong and bounded staleness
For writes, throughput is identical for all levels

44. Data Durability Region(s) Replication mode Consistency level RPO RTO 1
Single or Multi-Master
Any Consistency Level
< 240 Minutes
<1 Week
>1
Single Master
Session, Consistent Prefix, Eventual
< 15 minutes
Bounded Staleness
K & T
Strong
Multi-Master
In Cosmos, there is a relationship between the consistency level and data durability
you need to understand the maximum acceptable time before the application fully recovers after a disruptive event
The time required for an application to fully recover is known as recovery time objective (RTO).
You also need to understand the maximum period of recent data updates the application can tolerate losing when recovering after a disruptive event.
The time period of updates that you might afford to lose is known as recovery point objective (RPO).
In this table I’ve outlined the relationship between consistency and data durability should a region suffer an outage.

45. Conflicts types and how to resolve them
Occurs when we have multiple write regions
Can occur on inserts, replacements and deletes
Two Policies:
1. Last Write Wins
2. Custom (SQL API only)

46. Monitoring in Cosmos DB

47. HTTP Status Codes Code Meaning 200 OK 201 Created 204 No Content
GET, PUT or POST operation was successful
201 Created
Resource created successfully using a POST operation
204 No Content
Resource deleted successfully using a DELETE operation
401 Unauthorized
Invalid Authorization header
403 Forbidden
Authorization token expired
Resource quota reached when attempting to create a document Stored Procedure, Trigger or UDF is blacklisted from executed

48. HTTP Status Codes Header Value 409 Conflict 412 Precondition Failure
The item Id for a PUT or POST operation conflicts with an existing item
412 Precondition Failure
The specified eTag is different from the version on the server (optimistic concurrency error)
413 Entity Too Large
The item size exceeds maximum allowable document size of 2MB
429 Too Many Requests
Container has exceeded provisioned throughput limit
449 Retry With
Transient error has occurred, safe to retry

49. Activity Logging Subscription level events in Azure.
“Who, what, and when”.
For Cosmos, these are Control Plane Operations.
E.g Create Container, List Keys, Delete Keys etc.
The Azure Activity Log is a subscription log that provides insight into subscription-level events that have occurred in Azure
The Activity Log reports control-plane events for your subscriptions under the Administrative category.
You can use the Activity Log to determine the "what, who, and when" for any write operation (PUT, POST, DELETE) on the resources in your subscription.

50. Diagnostic Logging All authenticated backend requests.
Operations on the database itself
Operations on account keys.
Unauthenticated requests that generate 401 responses.
Diagnostic logs are produced by Azure Resources and provide rich data about the operation of that resource.
These are captured per request
These differ from resource to resource in Azure.
So specifically for Cosmos:
All authenticated backend requests across all APIs are logged, including failed operations such as access permissions or bad requests. At this time, I believe that user initiated requests for Graph, Cassandra and Table Cosmos API aren’t supported.
Operations on the database itself, including CRUD operations on documents, containers and databases.
Operations on account keys, including the creation, modifying or deletion of keys.
Unathenticated requests that generate 401 responses, this will be for requests that have invalid, malformed or missing tokens.

51. What can we log? Log Data What does it do? DataPlaneRequests
Logs all back-end requests to all APIs
MongoRequests
Logs user-initiated requests from the front end to serve requests to MongoDB API accounts.
QueryRuntimeStatistics
Logs the query text that was executed
Metric Requests
Verbose data in Azure Metrics
So what exactly can we log for Cosmos diagnostics
DataPlaneRequests: Select this option to log back-end requests to all APIs which includes SQL, Graph, MongoDB, Cassandra, and Table API accounts in Azure Cosmos DB.
MongoRequests: Select this option to log user-initiated requests from the front end to serve requests to Azure Cosmos DB's API for MongoDB. MongoDB requests will appear in MongoRequests as well as DataPlaneRequests. 
QueryRuntimeStatistics: Select this option to log the query text that was executed.
Metric Requests: Select this option to store verbose data in Azure metrics. 

52. Where can we send our logs?
Azure Storage
Event Hubs
Log Analytics
You can store the logs to the following services:
Archive to a storage account: To use this option, you need an existing storage account to connect to
Stream to an event hub: To use this option, you need an existing Event Hubs namespace and event hub to connect to.
Send to Log Analytics: To use this option, either use an existing workspace or create a new Log Analytics workspace

53. Metrics Metric What it shows Throughput
Number of requests consumed or failed because of throughput
Storage
Size of data and index used
Availability
% of successful requests over the total requests per hour
Latency
Read and write latency observed by Cosmos in the account region
Consistency
Shows how eventual the consistency is for our chosen model
System
How many metadata requests are served by master partition.
We can view Metrics on our Cosmos DB accounts to assess it’s performance.
We can use either the portal or the Azure Monitor API.
Collected every 5 minutes, kept for 7 days.

54. Security in Cosmos DB

55. IP Firewall Support Supports IP-based access controls
Configure accounts to be accessible from only approved IP’s and services.
Can combine with Vnet access control for more security.
Cosmos supports IP-based controls for inbound firewall support.
Similar to firewall rules of traditional database services
By default Cosmos is accessible from the internet as long as we have a valid token when m

56. Authorization: Master Keys
Provides access to all admin resources for our accounts.
Primary and Secondary keys.
Read only keys.
Keys can be regenerated.

57. Authorization: Resource Tokens
Provide access to specific resources within a database.
Specific containers, partition keys, documents etc.
Safer alternative to using master key.
Valid for a certain period of time (default 1 hour)
Set permissions at a user level.

58. Users and Permissions Users are associated with a Cosmos Database
Can contain zero or more users
Permissions are associated with a user
Provides access to a security token that the user needs when accessing a resource

59. RBAC controls Individuals in Azure AD can be assigned roles
Role assignments are scoped to control-plane access only.
Can be configured in IAM portal

60. Built-in roles Role Description DocumentDB Accounts Contributor
Can manage Azure Cosmos DB accounts.
Cosmos DB Account Reader
Can read Azure Cosmos DB account data.
Cosmos Backup Operator
Can submit restore request for an Azure Cosmos database or a container.
Cosmos DB Operator
Can provision Azure Cosmos accounts, databases, and containers but cannot access the keys that are required to access the data.
Cosmos DB provides built-in role-based access control (RBAC) for common scenarios in Azure Cosmos DB
Indiviudals that have Azure AD profiles can assign these RBAC roles to users as needed.
Role assignments are scoped to control-plane access only. Including access to accounts, databases and containers.
If these roles don’t suit all our needs, we can create custom roles for our purposes.

61. Encryption End-to-End encryption in Cosmos
Primary databases stored on SSDs
Media attachments and backups on Blob Storage (HDDs)
End-to-End encryption in Cosmos
Because all user data stored in Cosmos DB is encrypted at rest and in transport, you don't have to take any action
encryption at rest is "on" by default
Azure Cosmos DB uses AES-256 encryption on all regions where the account is running
Encryption keys are managed by Microsoft and there is no additional cost.

62. Backups

63. Backups Cosmos automatically back-ups your data.
Stored in a separate storage service
Globally replicated.
Stored in the same region as your Cosmos write region
Azure Cosmos DB stores these backups in Azure Blob storage whereas the actual data resides locally within Azure Cosmos DB.
 the snapshot of your backup is stored in Azure Blob storage in the same region as the current write region (or one of the write regions, in case you have a multi-master configuration) of your Azure Cosmos database account
For resiliency against regional disaster, each snapshot of the backup data in Azure Blob storage is again replicated to another region through geo-redundant storage (GRS). The region to which the backup is replicated is based on your source region and the regional pair associated with the source region
Cannot access this backup directly,

64. Managing our backups
Azure Data Factory
Change Feed

65. Backup Retention Period
Snapshots of our data every 4 hours
Only the last 2 snapshots are retained
If container or database is deleted, Cosmos retains snapshot for 30 days.

66. What happens during a restore?
Creates a new Cosmos account to hold restored data.
Can restore data into account with same name, provided that it’s not in use.
Whole Database or just a subset of containers.
For items within a container, you need to specify the time.
For database provisioned throughput, restores can’t take place at the Container level.

67. What we’ve covered today
What is Azure Cosmos DB?
Modelling our data
Working with Containers and Items
Distributing our data
Partitioning
Indexing Strategies
Provisioning Throughput
Monitoring Cosmos DB
Security
Backups

68. Cosmos DB Documentation
Want to learn more?
I’ve uploaded these slides to the SQL Saturday site, but if you want to learn more I’d really recommend that you take time to go over the documentation when you’re building your Cosmos DB databases.
If you want more hands on learning, make sure you check out the Microsoft Learn Cosmos courses.
Cosmos DB Documentation
Microsoft Learn

69. Thanks to our great Sponsors
Gold Sponsors
Silver Sponsors
Global Sponsors
Before I start, I just want to thank our sponsors for making SQL Saturday happen!
Bronze Sponsors

70. Thanks for listening!
So thanks for listening, hopefully you’ve gotten something out of it.
Any questions?