DP-203: Data Engineering on Microsoft Azure
What type of data model provides a traversal language that enables connections and traversals across connected data?
Gremlin API
Cassandra API
Table API
Mongo DB API
Answer is Gremlin API
Gremlin API is used to store Graph databases and provides a traversal language that enables connections and traversals across connected data. Cassandra API is used to store date from Cassandra databases. The Table API is used to store key-value pair of data and Mongo DB API is used to store Mongo DB databases.
Suppose you are using Visual Studio Code to develop a .NET Core application that accesses Azure Cosmos DB. You need to include the connection string for your database in your application configuration. What is the most convenient way to get this information into your project?
Directly from Visual Studio Code
From the Azure portal
Using the Azure CLI
Answer is Directly from Visual Studio Code
The Azure Cosmos DB extension lets you administer and create Azure Cosmos DB accounts and databases from within Visual Studio Code. The Azure Portal does not aid the development of a .Net Core Application, and Azure CLI helps more with automation.
When working with Azure Cosmos DB's SQL API, which of these can be used to perform CRUD operations?
LINQ
Apache Cassandra client libraries
Azure Table Storage libraries
Answer is LINQ
LINQ and SQL are two of the valid methods for querying the SQL API. Apache Cassandra client libraries is used for the Cassandra API and Azure Table Storage libraries for the Table API and not the SQL API.
When working with the Azure Cosmos DB Client SDK's DocumentClient class, you use a NOSQL model. How would you use this class to change the FirstName field of a Person Document from 'Ann' to 'Fran'?
Call UpdateDocumentAsync with FirstName=Fran
Call UpsertDocumentAsync with an updated Person object
Call ReplaceDocumentAsync with an updated Person object
Answer is Call ReplaceDocumentAsync with an updated Person object
ReplaceDocumentAsync will replace the existing document with the new one. In this case we'd intend the old and new to be the same other than FirstName.
The DocumentClient class doesn't have an UpdateDocumentAsync method. Updating a single field is not consistent with the document-style NOSQL approach.
While calling UpsertDocumentAsync with an updated Person object would work, it isn't the minimum necessary access to meet our requirements. Upsert operations will replace a document if its key already exists or add a new document if not. We don't want to add a new one, so using this method risks introducing subtle, hard to track bugs.
You plan to implement an Azure Cosmos DB database that will write 100,000 JSON every 24 hours. The database will be replicated to three regions. Only one region will be writable.
You need to select a consistency level for the database to meet the following requirements:
- Guarantee monotonic reads and writes within a session.
- Provide the fastest throughput.
- Provide the lowest latency.
Which consistency level should you select?
Strong
Bounded Staleness
Eventual
Session
Consistent Prefix
Answer is Session
Session: Within a single client session reads are guaranteed to honor the consistent-prefix (assuming a single “writer” session), monotonic reads, monotonic writes, read-your-writes, and write-follows-reads guarantees. Clients outside of the session performing writes will see eventual consistency.
References:
https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
You plan to deploy an Azure Cosmos DB database that supports multi-master replication.
You need to select a consistency level for the database to meet the following requirements:
- Provide a recovery point objective (RPO) of less than 15 minutes.
- Provide a recovery time objective (RTO) of zero minutes.
What are three possible consistency levels that you can select?
Strong
Bounded Staleness
Eventual
Session
Consistent Prefix
Answers are Consistent Prefix, Eventual, Session
References:
https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels-choosing
You have a container named Sales in an Azure Cosmos DB database. Sales has 120 GB of data. Each entry in Sales has the following structure.
{
OrderId: number,
OrderDetailId: number,
ProductName: string,
other information that might vary...
}
The partition key is set to the OrderId attribute.
Users report that when they perform queries that retrieve data by ProductName, the queries take longer than expected to complete.
You need to reduce the amount of time it takes to execute the problematic queries.
Solution: You create a lookup collection that uses ProductName as a partition key.
Does this meet the goal?
Yes
No
Answer is No
One option is to have a lookup collection “ProductName” for the mapping of “ProductName” to “OrderId”.
References:
https://azure.microsoft.com/sv-se/blog/azure-cosmos-db-partitioning-design-patterns-part-1/
You have a container named Sales in an Azure Cosmos DB database. Sales has 120 GB of data. Each entry in Sales has the following structure.
{
OrderId: number,
OrderDetailId: number,
ProductName: string,
other information that might vary...
}
The partition key is set to the OrderId attribute.
Users report that when they perform queries that retrieve data by ProductName, the queries take longer than expected to complete.
You need to reduce the amount of time it takes to execute the problematic queries.
Solution: You create a lookup collection that uses ProductName as a partition key and OrderId as a value.
Does this meet the goal?
Yes
No
Answer is Yes
One option is to have a lookup collection “ProductName” for the mapping of “ProductName” to “OrderId”.
References:
https://azure.microsoft.com/sv-se/blog/azure-cosmos-db-partitioning-design-patterns-part-1/
You have a container named Sales in an Azure Cosmos DB database. Sales has 120 GB of data. Each entry in Sales has the following structure.
{
OrderId: number,
OrderDetailId: number,
ProductName: string,
other information that might vary...
}
OrderId attribute.Users report that when they perform queries that retrieve data by
ProductName, the queries take longer than expected to complete.You need to reduce the amount of time it takes to execute the problematic queries.
Solution: You increase the Request Units (RUs) for the database.
Does this meet the goal?
Yes
No
Answer is Yes
To scale the provisioned throughput for your application, you can increase or decrease the number of RUs at any time.
Note: The cost of all database operations is normalized by Azure Cosmos DB and is expressed by Request Units (or RUs, for short). You can think of RUs per second as the currency for throughput. RUs per second is a rate-based currency. It abstracts the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.
Reference:
https://docs.microsoft.com/en-us/azure/cosmos-db/request-units
You have a container named Sales in an Azure Cosmos DB database. Sales has 120 GB of data. Each entry in Sales has the following structure.
{
OrderId: number,
OrderDetailId: number,
ProductName: string,
other information that might vary...
}
The partition key is set to the
OrderId attribute.Users report that when they perform queries that retrieve data by
ProductName, the queries take longer than expected to complete.You need to reduce the amount of time it takes to execute the problematic queries.
Solution: You change the partition key to include
ProductName.Does this meet the goal?
Yes
No
Answer is No
Explanation:
One option is to have a lookup collection “ProductName” for the mapping of “ProductName” to “OrderId”.
References:
https://azure.microsoft.com/sv-se/blog/azure-cosmos-db-partitioning-design-patterns-part-1/