What is Document DB?
It is a type of non-relational database that is designed to store and query data in JSON based documents.
What is Cosmos DB?
It is a universal and big database and technically it is an improvised version of document DB.
What is write and read database in Cosmos DB?
The primary database which is set on a region is called "write" database and for performance perspective it is replicated across globe can be called as "read" database
When an data in write database get replicated across read database?
As and when write an data in primary database it get reflected across all other read databases
Does it same like BCP, isn't ?
No, major difference is user will read data from BCP when primary (write) database goes down for some unexpected reason whereas here live data reflected in read database and this read database actively used in the application run on the appropriate region
What if user (application) access the data in "read" database when the latest data not replicated from "write" database?
Yes, in this case user (application) will read the old data from "read" database. Its called eventually consistent i.e., a state in which write and ready database data doesn't sync
Is it possible to stop reading user(application) in "read" database until the latest data replicated from "write" database?
Yes, its possible by configure the "read" database's consistent level.
i.e., configure as below
1) update happens in "write" database
2) "write" database sends replication details to all "read" databases
3) "write" database wait for all "read" database's acknowledgement back that they updated the given changes to them
4) "write" send a signal to all "read" database saying "you all are now have updated data"
5) "read" database allows its user(application) to access the data
What is strong and eventual consistency?
In strong consistency, data across all write and read database are same
In eventual consistency, data in write and ready databases are different (few read database reflect updated value and others doesn't)
What about performance and consistency level in strong and eventual ?
In strong consistency, the performance is very low and consistency level is high
In eventual consistency, the performance is very high and consistency level is very low
Does only 2 consistency level supported by CosmosDB?
No, this is the place where we can see CosmosDB's flexibility of having more consistency level as below
Strong
-
Consistent state. highest consistent, lower performance, lowest availability, highest latency
-
All "read" and "write" database has updated data
-
When is it best? application has more financial transaction, schedule
Bounded
-
Consistent state, performance is better than strong however the availability is still low due to inherent lag for the replication
-
"staleness" used to keep show the old data for the given amount of data
-
Ex: If we set "staleness" as 1 minute then all user(application) can see old data from both "write" & "read" database
-
If we set "staleness" as 0 then it become "Strong" consistent and user(application) have to wait until it get done with replication. i.e., it can't ready old & new value until then
-
When is it best? app doesn't need to fetch live-data but wants to read in the order it was written
Session
-
Partially inconsistent state, availability is high with lower latency and higher throughput than the bounded staleness
-
Users of "write" database can see the updated data where as other "read" database user see old data (stale data) until it get replicated from "write" db
-
When is it best? e-commerce app, social media app
Prefix
-
Inconsistent state, high availability and low latency
-
Sequence of changes done in write db reflects in the same order in "read" db and its users(application) are allowed to read those in same order
-
EX: a "write" db value updated as v1 => after 2 minutes => v2 => after 2 minutes v3
write db replicates these changes in same order to read db v1 => 2 minutes => v2 => v3
read db users can see v1 first and after 2 minutes see v2 and then v3. i.e., without wait user can keep access but data is not consistent -
When is it best? application afford the lag and still fulfill its requirement as expected
Eventual
-
Inconsistent state
-
Similar to prefix but order is not guarantee and don't know how long it take to replicate
-
When is it best? count of retweets is important than any other information
What is multi API support in CosmosDB?
Data is stored in {{JSON}} format and it can be retrieved using
1) SQL API
2) Mongo API
3) Graph API
4) Table API
5) Cassandra
Why do we need this multi API support ?
You want to migrate your database from SQL or Mongo or Cassandra to CosmosDB but want to continue with appropriate API written to access those data
Note: If you write an application from scratch then you can go with SQL API that is strongly recommended for working with Azure
How storage structure is maintained in CosmosDB?
Account >> Database >> Collection >> Documents >> {{JSON data}}
How to create CosmosDB in Azure?
Step 1: login Azure portal
Step 2: Click New (+)
Step 3: Type Azure Cosmos DB and select
Step 4: Create new Cosmost DB account
- ID ("mycosmosdb" => which populates URL => name.documents.azure.com)
- API (choose API SQL, MongoDB, Cassandra, Azure Table, Gremlin (graph) )
- Subscription (Pay-as-you-go)
- Resource Group (create new or use existing)
- Location (choose "Central US")
- Check "Enable geo-redundancy"
- Press "Create CosmosDB" button
Step 5: Once created, you can see a record with given account name "mycosmosdb"
Step 6: Click the account "mycosmosdb" and follow below steps to create a database
- click "collection"
- provide following details to create a collection
- database id, collection id, storage capacity (Fixed10GB/Unlimited), Partition key, Throughput (1000-1000000 RU)
How do we set consistency level in CosmosDB?
Step 1: select the database
Step 2: click "Replicate Data Globally" under Settings
Step 3: set which are all "write" region and "read" region
Step 4: click "Default Consistency" and choose one among STRONG|BOUNDED STALENESS|SESSION|CONSISTENT PREFIX|EVENTUAL
How do we set fail over (set more than one write database) database in CosmosDB?
Step 1: select the required cosmosDB account
Step 2: click "Manual failover"
Step 3: Reorder the regions under "READ REGIONS" sections which become write database in case of failover
Can you show C# application to connect CosmosDB?
class Program
{
static void Main(string[] args)
{
const string cosmosdbURL = @"https://mycosmosdb.documents.azure.com:443/";
const string cosmosdbKey = @"MK3sasdfasdQasdfdsAsdasdfAAsdf";
DocumentClient client;
client = new DocumentClient(new Uri(cosmosdbURL),cosmosdbkey);
FeedOptions qryOptions = new FeedOptions {MaxItemCount =-1};
IQuerable<q> qry = client.CreateDocumentQuery(q)(
foreach(var q in qry)
{
Console.WriteLine(" From {0}, q.id + q.name);
}
Console.Read();
}
}
Note: Click "Keys" under Settings in CosmosDB account and get URI, Primary Key, and also it has secondary key, primary & secondary connection string
Can you share official cosmos DB official DB?
https://azure.microsoft.com/en-in/services/cosmos-db/