AZURE COSMOS DB

18-Apr-2022
 INTRODUCTION TO COSMOS

 Azure Cosmos DB is a multi-model PaaS offering on Microsoft Azure. It is a NoSQL globally

distributed highly available database system with less than 10ms of latency for both reads and
writes.

 Azure Cosmos DB is a new globally distributed database. It can easily be scaled out
(horizontally partitioning), and it is widely available around the world.

 Azure Cosmos DB is a fully managed NoSQL database for modern app development. Single-
digit millisecond response times, and automatic and instant scalability, guarantee speed at any
scale. Business continuity is assured with SLA-backed availability and enterprise-grade security.
App development is faster and more productive.

© Copyright MSC Mediterranean Shipping Company S.A. 2

Sensitivity: Internal
 MICROSOFT AZURE COSMOS DB PROS AND CONS

PROS
 Highly available
 Seamless service with low latency
 Can be accessed through API
 Scalable Instantly and automatically serverless database for any large-scale business.
 Quick access and response to data queries due to high speed in reading and writing data
 Create a powerful digital experience for your customers with real-time offers and agile access to DB with super-fast analysis and
comparison for best recommendation

CONS
 When searching by default, it is case sensitive, which must be changed by default
 In many ways, the price should be more flexible according to the requested facilities, because the price is very expensive for startup companies.
 It is not fully compatible with most common Streaming Analytics tools applications and developers should be worked on it
 Expensive, so be careful of the use case.
 We had a thought time migrating from traditional DBs to Cosmos. Azure should provide a seamless platform for the migration of data from on-
premises to cloud.
 Cost, it's quite expensive.

© Copyright MSC Mediterranean Shipping Company S.A. 3

Sensitivity: Internal
 PARTITIONING AND INDEXING

Partitioning:
 Partition key plays an important role here. It is associated with each of the items inside a container and based on it’s value, the subsets or the
partitions are formed. Another important point to remember here is every items inside a specific container have the same partition key.
 The partition key is nothing but a JSON property that is responsible for distributing data among different partitions.
 Behind the scene, Partition key only decides where to place which document.
 Another important point to remember here is, once you set the partition key, it’s not possible to change the Partition key again.
 It is suggested to keep a partition key with many distinct values.

Indexing:
 Azure Cosmos DB is a schema-agnostic database that allows you to iterate on your application without having to deal with schema or index
management. By default, Azure Cosmos DB automatically indexes every property for all items in your container without the need to define any
schema or configure secondary indexes. If you chose to leave indexing policy at the default settings, you can run most queries with optimal
performance and never have to explicitly consider indexing
 Azure Cosmos DB persists our items within our containers as JSON documents. We can think of these documents as trees and each property in
Cosmos DB supports 3 kinds
our item as a node within that tree
of indexes:
Range Indexes
Spatial Indexes
© Copyright MSC Mediterranean Shipping Company S.A. 4
Composite Indexes
Sensitivity: Internal
 AZURE COSMOS COST MANAGEMENT

 Cosmos costs are strictly related to cost of requests.

 Request Unit measures the computational cost of each queries (read/write) and is based on the usage
of CPU, memory, IOPS for the request.
 1 RU is the cost to read a document of 1 KB getting it by unique key.
 Cosmos allows to define a throughput (i.e. RU per second) value either on database level or on
container level.
 Obviously the second allows to optimize the way of we can scale inside the same database, since we
can define different throughput for each container
 Manually, during the creation, for predictable and stable workloads.
 Auto scale, during the creation, for unpredictable and variable workloads. Auto scale working from
10% to 100% of settled max value.
 • serverless, pay per use, without reserved throughput, for spiky workloads, tests and demos. With
auto scale still have to pay the 10% always and anyway requires 1 hour rolling window to evaluate
how to scale

© Copyright MSC Mediterranean Shipping Company S.A. 5

Sensitivity: Internal