10 focus cards Flashcards
In Function Apps, how does Consumption and Premium plans scale? [6]
MOVE BACK TO MODULE ONE WHEN COMPLETE
Azure Functions in Consumption and Premium plans scale CPU and memory resources by adding more instances of the Functions host.
The number of instances is determined by the number of events that trigger a function.
In the Consumption plan, each instance of the Functions host is limited to 1.5 GB of memory and one CPU.
An instance of the host represents the entire function app, meaning all functions within a function app share resources within an instance and scale together.
Function apps that share the same Consumption plan scale independently.
In the Premium plan, the plan size determines the available memory and CPU for all apps in that plan on a specific instance.
Most scenarios that use the Azure Cosmos DB change feed use one of the push model options. However, there are some scenarios where you might want the additional low level control of the pull model. These include what? [3]
Reading changes from a particular partition key
Controlling the pace at which your client receives changes for processing
Doing a one-time read of the existing data in the change feed (for example, to do a data migration)
In Cosmos DB, when reading Azure Cosmos DB change feed, what are the two option, and what’s different about them? [3]
[1] You can work with the Azure Cosmos DB change feed using either a push model or a pull model.
[2] With a push model, the change feed processor pushes work to a client that has business logic for processing this work. However, the complexity in checking for work and storing state for the last processed work is handled within the change feed processor.
[3] With a pull model, the client has to pull the work from the server. The client, in this case, not only has business logic for processing work but also storing state for the last processed work, handling load balancing across multiple clients processing work in parallel, and handling errors.
In Cosmos DB, what is it and what are the benefits of using it? [5]
[1] Cosmos DB: Fully managed NoSQL database
[2] Low latency
[3] Elastic scalability of throughput
[4] Well-defined semantics for data consistency
[5] High availability
In Cosmos DB, what are the key benefits of global distribution?[6]
With its novel multi-master replication protocol, [1] every region supports both writes and reads. The multi-master capability also enables:
[2] Unlimited elastic write and read scalability.
[3] 99.999% read and write availability all around the world.
[4] Guaranteed reads and writes served in less than 10 milliseconds at the 99th percentile.
[5] Your application can perform near real-time reads and writes against all the regions you chose for your database. Azure Cosmos DB internally handles the data replication between regions with consistency level guarantees of the level you’ve selected.
[6] Running a database in multiple regions worldwide increases the availability of a database. If one region is unavailable, other regions automatically handle application requests. Azure Cosmos DB offers 99.999% read and write availability for multi-region databases.
In Cosmos DB, list all the consistency levels from strongest to weakest? [5]
Strong
Bounded staleness
Session
Consistent prefix
Eventual
In Cosmos DB, what are the characteristics of Bounded staleness consistency? [4]
In bounded staleness consistency, the reads are guaranteed to honor the consistent-prefix guarantee. The reads might lag behind writes by at most “K” versions (that is, “updates”) of an item or by “T” time interval, whichever is reached first. In other words, when you choose bounded staleness, the “staleness” can be configured in two ways:
[1] The number of versions (K) of the item
[2]The time interval (T) reads might lag behind the writes
[3] For a single region account, the minimum value of K and T is 10 write operations or 5 seconds. [4] For multi-region accounts the minimum value of K and T is 100,000 write operations or 300 seconds.
In Cosmos DB, what are the characteristics of Session consistency? [5]
[1] Consistent-Prefix: Reads will always show data that’s at least as up-to-date as the previous read within the same session.
[2] Monotonic Reads: Each read operation will never show you data older than what you’ve seen before in that session. It’s always moving forward.
[3] Monotonic Writes: If you’ve written some data in your session, you will never see a situation where your writes get “undone” or overwritten by older data in the same session.
[4] Read-Your-Writes: Any data you write within your session will always be visible when you read it in the same session. In other words, you’ll see your own writes.
[5] Write-Follows-Reads: If you read data and then write new data in your session, your writes will not happen before your previous reads.
Extract for MS Learn:
In session consistency, within a single client session reads are guaranteed to honor the consistent-prefix, monotonic reads, monotonic writes, read-your-writes, and write-follows-reads guarantees. This assumes a single “writer” session or sharing the session token for multiple writers.
In Cosmos DB, what are the characteristics of Consistent prefix consistency? [4]
In consistent prefix, updates made as single document writes see eventual consistency. Updates made as a batch within a transaction, are returned consistent to the transaction in which they were committed. Write operations within a transaction of multiple documents are always visible together.
[1] Assume two write operations are performed on documents Doc 1 and Doc 2, within transactions T1 and T2. When client does a read in any replica, the user sees either [2] “Doc 1 v1 and Doc 2 v1” [3] or “Doc 1 v2 and Doc 2 v2”, [4] but never “Doc 1 v1 and Doc 2 v2” or “Doc 1 v2 and Doc 2 v1” for the same read or query operation.
In Cosmos DB, what are the characteristics of Eventual consistency? [4]
In eventual consistency, [1] there’s no ordering guarantee for reads. In the absence of any further writes, the replicas eventually converge.
[2] Eventual consistency is the weakest form of consistency because a client may read the values that are older than the ones it read before. [3] Eventual consistency is ideal where the application doesn’t require any ordering guarantees. [4] Examples include count of Retweets, Likes, or nonthreaded comments
