Azure Cosmos DB Fun Facts

Par -

How to Use Azure Cosmos DB

  1. Create an Azure Cosmos DB account (Account Name: A unique name to identify your Azure Cosmos account. The name can only contain lowercase letters, numbers, and the hyphen (-) character. It must be between 3-31 characters in length.)
  2. Add a database and a container
  3. Add data to your database
You can use the Data Explorer in the Azure portal to create a database and container.With Azure Cosmos DB, you pay for the throughput you provision and the storage you consume on an hourly basis. Throughput must be provisioned to ensure that sufficient system resources are available for your Azure Cosmos database always.

Consistency levels

Azure Cosmos DB approaches data consistency as a spectrum of choices and offers five well-defined levels.
You can configure the default consistency level on your Azure Cosmos DB account at any time. The default consistency level configured on your account applies to all Azure Cosmos DB databases and containers under that account.
From strongest to weakest, the levels are as following.

Strong

Linearizability guarantee.
Linearizability refers to serving requests concurrently. The reads are guaranteed to return the most recent committed version of an item. A client never sees an uncommitted or partial write. Users are always guaranteed to read the latest committed write.

Bounded staleness consistency

Consistent Prefix. Reads lag behind writes by k prefixes or t interval
In bounded staleness consistency, the lag of data between any two regions is always less than a specified amount. The amount can be K versions (that is, updates) of an item or by T time intervals, whichever is reached first. In other words, when you choose bounded staleness, the maximum "staleness" of the data in any region can be configured in two ways:
  • The number of versions (K) of the item
  • The time interval (T) reads might lag behind the writes
Bounded Staleness is beneficial primarily to single-region write accounts with two or more regions. If the data lag in a region (determined per physical partition) exceeds the configured staleness value, writes for that partition are throttled until staleness is back within the configured upper bound.

For a single-region account, Bounded Staleness provides the same write consistency guarantees as Session and Eventual Consistency. With Bounded Staleness, data is replicated to a local majority (three replicas in a four replica set) in the single region. 

Session consistency

Consistent Prefix. Monotonic reads, monotonic writes, read-your-writes, write-follows-reads
In session consistency, within a single client session, reads are guaranteed to honor the read-your-writes, and write-follows-reads guarantees. This guarantee assumes a single “writer" session or sharing the session token for multiple writers.

Like all consistency levels weaker than Strong, writes are replicated to a minimum of three replicas (in a four replica set) in the local region, with asynchronous replication to all other regions.

Consistent prefix consistency

Updates returned are some prefix of all the updates, with no gaps
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.

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 "Doc 1 v1 and Doc 2 v1" or "Doc 1 v2 and Doc 2 v2," but never "Doc 1 v1 and Doc 2 v2" or "Doc 1 v2 and Doc 2 v1" for the same read or query operation.

Eventual consistency

Eventual
In eventual consistency, there's no ordering guarantee for reads. In the absence of any further writes, the replicas eventually converge.
Eventual consistency is the weakest form of consistency because a client might read the values that are older than the ones it read before. Eventual consistency is ideal where the application doesn't require any ordering guarantees. Examples include count of Retweets, Likes, or nonthreaded comments

Cost

The cost of all database operations is normalized in Azure Cosmos DB and expressed by request units (or RUs, for short). A request unit represents the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.

The cost to do a point read, which is fetching a single item by its ID and partition key value, for a 1-KB item is 1RU. All other database operations are similarly assigned a cost using RUs. No matter which API you use to interact with your Azure Cosmos container, costs are measured by RUs. Whether the database operation is a write, point read, or query, costs are measured in RUs.

In a stored procedure, the context object provides access to all operations that can be performed in Azure Cosmos DB, and access to the request and response objects.

Pretriggers are executed before modifying a database item and must be specified for each database operation where you want them to execute.

The consistency levels offers the greatest throughput.

In Azure Cosmos DB, request units (RUs) are a unit of measurement used to express the cost of all database operations in Azure Cosmos DB.

The type of Azure Cosmos DB account you're using determines the way consumed RUs get charged. 

There are two modes for account creation:

Provisioned throughput mode

In this mode, you provision the number of RUs for your application on a per-second basis in increments of 100 RUs per second. To scale the provisioned throughput for your application, you can increase or decrease the number of RUs at any time in increments or decrements of 100 RUs. You can make your changes either programmatically or by using the Azure portal. You can provision throughput at container and database granularity level.

Serverless mode

In this mode, you don't have to provision any throughput when creating resources in your Azure Cosmos DB account. At the end of your billing period, you get billed for the number of request units consumed by your database operations.

Notification des changements

change feed notifications in Azure Cosmos DB. The change feed processor in Azure Cosmos DB simplifies the process of reading the change feed and can be used to distribute the event processing across multiple consumers effectively. 

There are four main components in the change feed processor: the monitored container, the lease container, the compute instance, and the delegate. 

The monitored container has the data from which the change feed is generated. 

The delegate component can be used to define custom logic to process the changes that the change feed reads. 

The compute instance hosts the change feed processor to listen for changes. It can be represented by a VM, a Kubernetes pod, an Azure App Service instance, or an actual physical machine. 

The lease container acts as a state storage and coordinates the processing of the change feed across multiple workers.

SDK

The ReadItemAsync method of the container class of .NET SDK for Azure Cosmos DB has two mandatory parameters: partitionKey and itemId. The consistencyLevel parameter is part of the optional requestOptions parameter of the ReadItemAsync.

The eTag and sessionToken parameters are part of the optional requestOptions parameter of the ReadItemAsync method.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Conception logicielle en 2024

Par -
On commence par les bases de la conception logicielle, avec les Principes SOLID  et notamment le Principe de Responsabilité Unique . De nombreux  modèles de conception  existent et il faut savoir reconnaitre leur cas d'utilisation et les utiliser à bon escient, les  Modèles de Conception Comportementaux , les  Modèles de Conception de Construction  et les  Modèles de Conception Structuraux . La  Conception Pilotée par le Domaine (DDD)  d'une solution fondée sur une  Architecture Hexagonale est aujourd'hui l'approche recommandée. En utilisant de vieux modèles comme le  Modèle EBI , le  CQRS , le  Modèle d'Approvisionnement en Evènements , l' Inversion de Contrôle (IoC) et l'Injection des Dépendances (DI) . La  Méthode ITIL et Gestion des Incidents  n'ont pas toutes été oubliées par les décideurs. Développement Le développement piloté par les tests (TDD)  reste une approche fondamentalement positive. Le...
Lire la suite

DeFi - Définition

Par -
Introduction La finance est l'ensemble des processus de création, de gestion et d'investissement et de l'argent et des instruments financiers, les biens non physiques dont la valeur est contractuelle comme les dépots bancaires, les actions, obligations, emprunts et dérivés. Les établissements financiers sont les intervenants qui vont permettre la manipulation de ces instruments financiers en fournissant des services bancaires ou des prêts, la possibilité d'acheter des actions ou d'investir dans des fonds ou des véhicules d'investissement. Les marchés financiers sont des places de marché, ou les etablissements financiers se retrouvent pour vendre et acheter des produits financiers pour leur compte propre ou ceux de leurs clients. Finance Centralisée (CeFi - Centralized Finance) Les banques, courtiers, fond d'investissements, compagnie d'assurance sont autant d'établissement financiers de la finance.  Ils sont dépositaires des valeurs qui leur sont rem...
Lire la suite

Feuilles de Styles en Cascade

Par -
CSS A CSS rule-set consists of a selector and a declaration block. The selector points to the HTML element you want to style. The declaration block contains one or more declarations separated by semicolons. Each declaration includes a CSS property name and a value, separated by a colon. A CSS declaration always ends with a semicolon, and declaration blocks are surrounded by curly braces. In the following example all <p> elements will be center-aligned, with a red text color: <code> p { color: red; text-align: center; } </code> ===== CSS selectors ===== ==== The element Selector ==== The element selector selects elements based on the element name. <code> p { color: red; text-align: center; } </code> ==== The id Selector ==== The id selector uses the id attribute of an HTML element to select a specific element. The id of an element should be unique within a page, so the id selector is used to select one unique element! To select an element with a specific id...
Lire la suite