Cosmos DB

En interne, Cosmos DB stocke les « éléments » dans des « conteneurs » , ces deux concepts étant présentés différemment selon l' API utilisée (par exemple, il s'agirait de « documents » dans des « collections » avec l'API compatible MongoDB). Les conteneurs sont regroupés dans des « bases de données », analogues aux espaces de noms situés au-dessus des conteneurs. Les conteneurs sont indépendants du schéma, ce qui signifie qu'aucun schéma n'est imposé lors de l'ajout d'éléments.

Par défaut, chaque champ de chaque élément est automatiquement indexé, ce qui garantit généralement de bonnes performances sans nécessiter d'ajustements spécifiques aux requêtes. Ces paramètres par défaut peuvent être modifiés en définissant une stratégie d'indexation qui spécifie, pour chaque champ, le type d'index et la précision souhaités. Cosmos DB propose deux types d'index :

• plage, plage de support et requêtes ORDER BY
• spatial, prenant en charge les requêtes spatiales à partir de points, de polygones et de chaînes de lignes encodées dans des fragments GeoJSON standard

Les conteneurs peuvent également imposer des contraintes de clés uniques pour garantir l'intégrité des données.

Chaque conteneur Cosmos DB expose un flux de modifications auquel les clients peuvent s'abonner pour être notifiés des nouveaux éléments ajoutés ou mis à jour dans le conteneur. Au 0,008 $/ h , soit pour chaque client ; il s'agit du niveau de cohérence par défaut

Le niveau de cohérence souhaité est défini au niveau du compte, mais peut être modifié pour chaque requête à l'aide d'un en-tête HTTP spécifique ou de la fonctionnalité correspondante exposée par les SDK. Les cinq niveaux de cohérence ont été spécifiés et vérifiés à l'aide du langage de spécification TLA+ , dont le modèle TLA+ est disponible en open source sur GitHub.

Le modèle de distribution initial de Cosmos DB repose sur une seule région d'écriture, toutes les autres régions étant des réplicas en lecture seule. En mars 2018, Microsoft a annoncé une nouvelle fonctionnalité multi-maître pour Azure Cosmos DB, permettant à plusieurs régions de servir de réplicas en écriture. Cette fonctionnalité a considérablement amélioré le modèle initial à région d'écriture unique, où les autres régions étaient en lecture seule. Avec le modèle multi-maître, les écritures simultanées provenant de différentes régions peuvent engendrer des conflits potentiels, qui peuvent être résolus soit par la stratégie par défaut « Dernière écriture prioritaire » (LWW), soit par un mécanisme de résolution de conflits personnalisé, tel qu'une fonction JavaScript. La stratégie LWW s'appuie sur les horodatages pour déterminer l'écriture prioritaire, tandis que l'option personnalisée permet aux développeurs de gérer les conflits via une règle définie par l'application.

Cette fonctionnalité, annoncée en mai 2020 est un stockage en colonnes entièrement isolé permettant l'analyse à grande échelle des données opérationnelles dans Azure Cosmos DB, sans impact sur les charges de travail transactionnelles. Elle résout les problèmes de complexité et de latence liés aux pipelines ETL traditionnels , nécessaires à un référentiel de données optimisé pour le traitement analytique en ligne ( OLAP). Pour ce faire, elle synchronise automatiquement les données opérationnelles dans un stockage en colonnes distinct, adapté aux requêtes analytiques à grande échelle, afin de les exécuter de manière optimisée et d'améliorer ainsi leur latence.

Grâce à Microsoft Azure Synapse Link pour Cosmos DB, il est possible de créer des solutions de traitement transactionnel/analytique hybrides sans ETL en se connectant directement à la base de données analytique Azure Cosmos DB depuis Synapse Analytics. Ceci permet d'exécuter des analyses à grande échelle en quasi temps réel directement sur les données opérationnelles.

Microsoft utilise Cosmos DB dans plusieurs de ses propres applications, notamment Microsoft Office , Skype , Active Directory , Xbox et MSN .

Cosmos DB s'associe à d'autres services Azure, tels qu'Azure App Services et Azure Traffic Manager, pour créer une application plus résiliente.

L’outil d’optimisation des coûts cloud Cosmos DB Profiler détecte les requêtes de données inefficaces dans les interactions entre une application et sa base de données Cosmos DB. Le profileur alerte les utilisateurs sur les performances gaspillées et les dépenses cloud excessives. Il recommande également des solutions en isolant et en analysant le code, et en indiquant précisément l’emplacement du problème.

• SQL est limité. Les agrégations se limitent aux fonctions COUNT, SUM, MIN, MAX et AVG, mais ne prennent pas en charge GROUP BY ni d'autres fonctionnalités d'agrégation présentes dans les systèmes de bases de données. Cependant, les procédures stockées peuvent être utilisées pour implémenter des fonctionnalités d'agrégation au sein de la base de données.
• Les jointures SQL entre « tables » ne sont pas possibles.
• Cosmos DB ne prend en charge que les types de données JSON purs. Notamment, il ne gère pas les données de date et d'heure, ce qui vous oblige à les stocker dans les types de données disponibles. Par exemple, elles peuvent être stockées sous forme de chaîne ISO-8601 ou d'entier Unoch. MongoDB , la base de données à laquelle Cosmos DB est le plus souvent comparée, a étendu JSON dans sa spécification de sérialisation binaire BSON pour couvrir les données de date et d'heure ainsi que les types numériques classiques, les expressions régulières et le type Undefined.