Session de présentation CosmosDB au Global Azure Bootcamp 2019 de Strasbourg. Focus sur les grand principes techniques spécifiques à la base de données cloud d'Azure, et étude de cas pour l'illustration des principes d'optimisation des requêtes.

1. STRASBOURG
Cosmos DB

2. Globally distributed,
massively scalable,
and multi-model database service
Cosmos DB

3. Globally distributed,
massively scalable,
and multi-model database service
Cosmos DB

4. Philippe DIDIERGEORGES
CTO @ Versusmind
MUG Strasbourg
@DePhiless
Speaker

5. CosmosDB
Introduction et concepts

6. Exemple: service de log
• Application scalée pour qques Go
• Déployée en France
• Déployée petit à petit dans le monde entier
• De plus en plus de données: plusieurs peta
Problématiques
• Garder un niveau de perf constant
• Gérer les évolution

7. Dans le monde relationnel
Le problème des migrations
Quand le modèle change:
• Il faut préparer les scripts de migrations
• S’assurer qu’il s’exécute bien
• S’assurer que les changement nécessaire sont effectués (cascade)

8. Passer au modèle « NoSQL » avec CosmosDB
Document = Objet
• Pas de mapping complexe ni de génération de requête
• Schéma agnostique == pas de migration
Je code, j’initialise mon objet et je le persiste.

9. ?Si ce n’est pas du SQL, comment requêter mes
données?

10. NoSQL == Not Only SQL

11. ?Pourquoi le NoSQL n’est-il pas la norme depuis 15 ans?

12. Base de données cloud: les grands principes
Partitionnement
Réplication
Gouvernance des ressources

13. Partitionnement
Elasticité à l’infini du stockage et du débit

14. Réplication
Partitionnement
=> Elasticité à l’infini du stockage et du débit
Replication
Gouvernance des resources

15. ?Quel problème apparait lorsque l’on réplique des
données en plusieurs endroit?

16. Réplication
5 Stratégies de gestion de la consistance des données disponibles:
https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels

17. Gouvernance et Garanties
Pilotage de l’espace et du débit
- Provisionnement des ressource partagé ou ciblé
SLA de 1er ordre:
- 99,99% de disponibilité
- Latence <10ms garantie au 99e centile
- Débit et consistance des données garanties
Paiement à l’utilisation
=> Attention à l’optimisation!

18. Modélisation
En pratique, comment construit-on notre base de
données?

19. Structure des bases CosmosDB
Les conteneurs:
- Unité de scalabilité
- Répliqués entre les régions
- Débit (througput) réservé / partagé
- Options de TTL, indexation, …

20. Structure des bases CosmosDB
Les Items:
- Organisés dans des partitions logiques
avec la PartitionKey
Triggers, ProcStoc, Merge proc et UDF
écrites en JS

21. Notre contexte
Nous disposons de services
Ces services sont composés d’applications
Les applications génèrent des logs techniques contenant un environnement,
une criticité, un message et une stacktrace
Une page permet d’afficher les derniers logs et de requêter ces logs selon
des filtres.
Il est possible de consulter le détail d’un log et d’y trouver les informations
de l’environnement et de l’application.
Un état du service et de ses applications est disponible en fonction des logs
sur la dernière heure.

22. Le cas de notre application de logs
L’approche relationnelle
Applications
AppID
AppName
AppUrl
EnvName
SrvID
Service
SrvID
SrvName
Logs
LogID
LogLevel
Message
StackTrace
AppID

23. Analysons les requêtes
1. Identification des requêtes
2. Catégoriser les requêtes
• Command (écritures)
• Query (lectures)

24. Analysons les requêtes
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

25. Volumes de données
• 5 services
• 2 – 10 applications par service
• 5000 – 500.000 logs par jour / application

26. Limites du système relationnel
• La quantité de données impacte directement les performances
• La mise en place d’indexes permettra d’optimiser les requêtes
• Les jointures sont très consommatrices

27. Le modèle de données de CosmosDB

28. Le modèle de données de CosmosDB
Dans CosmosDB, on stocke des documents dans des conteneurs
> Comme des lignes dans une table?
NON

29. Le cas de notre application de logs
Dans CosmosDB, on stocke des documents dans des conteneurs

30. Analysons les requêtes – V0
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

31. Etape 1: partionnement

32. Etape 1: partitionnement
Au niveau des données: les conteneurs
Services Container
Applications Logs
PartitionKey: AppID
Type: "app"
AppID
AppName
AppUrl
EnvName
SrvID
Services
PartitionKey: SrvID
SrvID
SrvName
PartitionKey: AppID
Type: "log"
LogID
LogLevel
Message
StackTrace
AppID
Applications Container

33. Etape 1: partitionnement
Au niveau des données: les partitions logiques
Services Container
Applications Logs
PartitionKey: AppID
Type: "app"
AppID
AppName
AppUrl
EnvName
SrvID
Services
PartitionKey: SrvID
SrvID
SrvName
PartitionKey: AppID
Type: "log"
LogID
LogLevel
Message
StackTrace
AppID
Applications Container

34. Services Container
Etape 1: partitionnement
Au niveau des données: les partitions logiques
Applications Logs
PartitionKey: AppID
Type: "app"
AppID
AppName
AppUrl
EnvName
SrvID
Services
PartitionKey: SrvID
SrvID
SrvName
PartitionKey: AppID
Type: "log"
LogID
LogLevel
Message
StackTrace
AppID
Applications Container

35. Analysons les requêtes – V0
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

36. Analysons les requêtes – V1
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

37. Etape 2: Dénormalisation

38. Introduction: dénormalisation
Enrichir les données dans les documents
Rassembler les données de plusieurs tables en une seule
Objectif: réduire le besoin de jointure pour optimiser les requêtes les
plus gourmandes

39. Utilisation de procédures stockées
• Ecrites en Javascript
• Exécutée comme une transaction atomique
• Limitée à une seule partition logique
Dénormalisation dans la même partition
logique

40. Services Container
Applications Logs
PartitionKey: AppID
Type: "app"
AppID
AppName
AppUrl
EnvName
SrvID
SrvName
Services
PartitionKey: SrvID
SrvID
SrvName
PartitionKey: AppID
Type: "log"
LogID
LogLevel
Message
StackTrace
AppID
AppName
SrvID
SrvName
Applications Container
Dénormalisation dans la même partition
logique

41. Analysons les requêtes – V1
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

42. Analysons les requêtes – V2
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

43. Dénormalisation entre partitions et
conteneurs avec le change feed

44. Services Container
Applications Logs
PartitionKey: AppID
Type: "app"
AppID
AppName
AppUrl
EnvName
SrvID
SrvName
AppStatus
Services
PartitionKey: SrvID
SrvID
SrvName
SrvStatus
PartitionKey: AppID
Type: "log"
LogID
LogLevel
Message
StackTrace
AppID
AppName
SrvID
SrvName
Applications Container
Dénormalisation entre partitions et
conteneurs avec le change feed
Last100 Container
Logs
PartitionKey: type
Type: applog/srvlog
LogID
LogLevel
Message
StackTrace
AppID
AppName
SrvID
SrvName

45. Analysons les requêtes – V2
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

46. Analysons les requêtes – V3
• [C1] Ajouter / modifier un service
• [Q1] Consulter un service
• [C2] Ajouter / modifier une app
• [Q2] Consulter une app
• [Q3] Lister les apps d’un service et leur état
• [C3] Ajouter un log
• [Q4] Lister les logs d’une application / d’un service
• [Q5] Lister les logs (avec nom du service et de l’app)
• Les 100 derniers
• Pour un service / une application donnée
• Pour un environnement donné
• Pour une criticité donnée

47. Intégration grâce au change feed
=> Le change feed permet d’imaginer de nombreux scénarii
Architecture orientée événements

48. Intégration grâce au change feed
=> Analyse et exploitation temps réel des données
Architecture orientée événements

49. Intégration grâce au change feed
=> Système de recommandation
Architecture orientée événements

50. One more thing
Recherche full-text avec CosmosDB et Azure Search

51. ?Intéressés par un atelier CosmosDB?

52. Merci 
@DePhiless