Base de données Microsoft Cosmos (API DocumentDB) et base de données Cosmos (API de table)
Microsoft Cosmos DB inclut les API DocumentDB, Table API et autres. J'ai environ ~ 10 TB de données et j'aimerais effectuer une recherche rapide clé-valeur (très peu de mises à jour et d'écriture, principalement en lecture). Ajoutez un lien pour Microsoft Cosmos DB: https://docs.Microsoft.com/en-us/Azure/cosmos-db/
- Alors, comment choisir entre l'API DocumentDB et l'API Table?
- Ou quand devrais-je choisir l'API DocumentDB? Quand devrais-je choisir l'API de table?
- Est-ce une bonne pratique d’utiliser l’API DcoumentDB pour stocker 10 TB de données?
Alors, comment dois-je choisir entre l'API DocumentDB et l'API Table?
Le choix entre DocumentDB API et Table API dépendra principalement du type de données que vous allez stocker. DocumentDB API fournit un schema-less JSON database engine with SQL querying capabilities alors que Table API fournit un key-value storage database service. Puisque vous avez mentionné que vos données sont basées sur key-value, il est recommandé d’utiliser Table API.
Ou quand devrais-je choisir l'API DocumentDB? Quand devrais-je choisir l'API de table?
Comme ci-dessus.
Est-ce une bonne pratique d’utiliser l’API DcoumentDB pour stocker 10 TB de données?
Document DB API et Table API sont tous deux conçus pour stocker d’énormes quantités de données.
Cependant, vous voudrez peut-être aussi regarder dans Azure Table Storage. Cosmos DB vous permet d’ajuster avec précision le débit dont vous avez besoin et une prise en charge robuste de l’indexation/interrogation, ce qui a un prix. Azure Tables, d’autre part, est fourni avec un débit fixe et une prise en charge limitée de l’indexation/interrogation et est extrêmement bon marché par rapport à Cosmos DB.
Ce lien peut vous être utile pour en savoir plus sur Cosmos DB: https://docs.Microsoft.com/en-us/Azure/cosmos-db/introduction .
L'API de table Azure Cosmos DB Table a été introduite pour permettre à Cosmos DB et à ses fonctionnalités avancées d'indexation, de géo-distribution, etc. d'être disponibles pour la communauté de stockage Azure Table. L'idée est qu'une personne utilisant le stockage Azure Table et qui a besoin de fonctionnalités plus avancées uniquement proposées par Cosmos DB peut littéralement changer de chaîne de connexion et que son code existant fonctionnera avec Cosmos DB.
Mais si vous êtes un client greenfield, je vous recommanderais d'utiliser l'API SQL (anciennement appelée API Document DB), qui est un super ensemble d'API de table. Nous investissons en permanence dans la fourniture de fonctionnalités et de fonctionnalités plus avancées à l'API SQL. En ce qui concerne l'API Table, nous cherchons simplement à maintenir la compatibilité avec l'API de stockage Azure Table, qui n'a pas changé depuis de nombreuses années.
La quantité de données que vous possédez n’a aucune incidence sur l’API choisie. Ils ont tous les deux la même infrastructure multimodèle et peuvent gérer les mêmes tailles de données, charges de requête, distribution, etc.
S'il vous plaît ne pas signaler cela comme hors sujet.
Cela peut vous aider de savoir à l'avance: si vous envisagez l'interface de document, il existe en fait une insensibilité à la casse qui peut affecter la façon dont les classes DataContract (et toutes les autres, selon DataContract) sont transformées vers et à partir de Cosmos.
Dans la discussion liée ci-dessous, vous verrez qu'il y a une insensibilité à la casse dans Newtonsoft.Json qui peut avoir des effets sur votre gestion des objets que vous transmettez ou obtenez directement à partir de l'API. Non pas que Cosmos ait AUCUN défaut, et en fait, il est totalement excellent. Comme avec une API de document, vous pourriez (comme moi) commencer à simplement passer des objets DataContract à Cosmos (ce qui n’est évidemment pas faux et qui est en fait très attendu de l’API des objets), mais il existe des options de gestionnaire de stratégie de sérialisation et de nommage qui il vaut probablement mieux au moins en être conscient dès le départ.
Donc, juste pour ajouter une note pour que vous soyez conscient de ce comportement avec une interface d'objet. La discussion est ici sur GitHub: