Cosmos DB is the fully managed NoSQL database service provided by Azure. This meetup aims to give to the technical people the knowledge, approaches and guidelines to work with CosmosDB and bring from it the maximum benefits.
2. Starting to work in IT on 2006:
● Developer
● IT Consultant
● Project Manager
● Software Engineer
● Tech Lead Cloud Solution
GIORGIO DESIDERI
Who am I ?
4. ● Cosmos DB
○ Service description
○ DB Model supported
● First Contact
○ How approach to Cosmos DB
○ Examples
● Cosmos DB in Deep
○ Consistency level
○ Request Units concepts
● Considerations
AGENDA
What we are going to “Seven Peaks Speaks” about
6. ● Be a Developer
○ Analyze and Consider before to do the code
○ Avoid to focus only on code
○ Avoid to apply the way “this is fashion, so I will use it”
● NoSQL concepts
○ SQL definition
○ NoSQL definition
○ Data model is focused upon Denormalization
PRE-FACE
A checklist to pass before to start to enter into Cosmos DB
8. ● Azure Cosmos DB
○ NoSQL Database
○ PaaS
○ Globally distributed
○ Model execution
■ Provisioned
■ Serverless
Azure Cosmos DB
Service Description
9. Azure Cosmos DB
Resource Model
Logical grouping of database.
Here there is the API model definition
It is the base of the data where the
data are stored. It is the logical group
of the data
Schema-agnostic container of items
11. ● API model
○ Core/SQL API
■ Follow the SQL syntax for the instructions ( queries )
○ MongoDB API
■ Document model
○ Cassandra API
■ Multi key-values model
○ Gremlin API
■ Graph model
○ Storage Table API
Azure Cosmos DB
API model
12. 1st Contact
What we have to do, to do what we want to do avoid what we don’t want to do !
13. ● Is it a migration from existing NoSQL database ( MongoDB /
Cassandra / Gremlin / Storage Table, etc. )?
○ YES, the choice is done!
○ NO, see next.
Azure Cosmos DB
How to choose the right API Model ?
14. ● Do you have the data ?
○ YES
■ What model of NoSQL can fit those data ?
● Semi-Structured model
● Document model
● Key-value model
● Graph model
○ NO
■ CORE API as default
■ Write a PoC
Azure Cosmos DB
How to choose the right API Model ?
16. Azure Cosmos DB
Example
● Product Catalog
○ CORE API
○ Reason:
■ Semi-structured data
■ Multi search typed-data
17. Azure Cosmos DB
Example
● Order History
○ Mongo DB or Table API
○ Reason:
■ Document-structure data.
■ No search
■ Directly access to the single item
18. Azure Cosmos DB
Example
● Recommended Engine
○ Gremlin API
○ Reason:
■ Graph model
■ Multi-search and aggregation search
19. Azure Cosmos DB
Example
● Web Analytics
○ Cassandra API
○ Reason:
■ Key-Value model
■ Column Family for N-N relationships with small data
20. Azure Cosmos DB
Example
● IoT System
○ Azure Table API
○ Reason:
■ Store-only
■ Minimum of the structured data
■ Huge Storage capacity
23. Azure Cosmos DB
Request Unit
● Request Units
○ Request unit usage is measured per second, so the unit of
measure is request units per second (RU/s).
○ The number of RU consumed for an operation changes
depending on :
■ the document size
■ the number of properties in the document
■ the operation being performed
■ consistency level
■ indexing policy
24. Azure Cosmos DB
Request Unit
● Throughput of Request Unit
○ Dedicated or Shared
○ Manual
■ Per database
■ Per container
○ Autoscale
■ Define the Max RU/s to use
26. Azure Cosmos DB
Consistency Level
● How to define the throughput that I need?
○ Choose the right API model of Cosmos DB
○ PoC
■ Identify the most valuable features
■ Develop the most valuable features
■ Start from the minimum RU/s ( 400 or 100 )
■ Test as a maniac
● Business Logic Testing
● Performance Testing
■ Review the reports
■ Go to point #3
27. Azure Cosmos DB
Consistency Level
● Product Catalog
○ Start with 400 RU/s
○ Define the main categories of products
○ Batch insert an average 50 products per category
○ Create the model of the usage of your catalog
○ Test focusing on
■ Search the product by category, name
■ Scale user numbers 1 - 10 - 100 - 250 - 500 …
○ See the results
■ Can use the Azure Synapse Link
29. Azure Cosmos DB
Consistency Level
● Migration to cloud
○ Consider what you have
● Plan the API model to use according the data model that you
have or will have
● Take in serious consideration the model of “experiment” first,
and decide basing on the experiment
○ Risk #1, model doesn’t fit the reality
○ Risk #2, monitoring of the production to predict the
possible changes
○ Risk #3, rewrite the model or PoC because is not flexible
enough