Blogue

Azure DocumentDB en production!

Nous avons eu l’opportunité d’essayer une nouvelle base de données récemment publié en avril 2015. En effet, Microsoft a décidé d’ajouter à leurs services de « Cloud » leur première base de données « NoSQL ».

Qu’est ce que DocumentDB ?

Brièvement, Microsoft considère DocumentDB comme étant un « Database as a Service », qui persiste ses données en JSON et qui permet des requêtes flexibles (par exemple en SQL). Comme c’est un service de base de données, on ne gère pratiquement pas l’infrastructure et celle-ci est « scalable » jusqu’à l’infini, rapporte Microsoft.

Comment DocumentDB fonctionne globalement?

DocumentDB utilise les termes « base de données », « collection » et « document ».
Un document représente une entrée, une donnée ou une entité. Ces documents sont placés dans des collections, qui sont considérés comme des conteneurs. Les collections, à leur tour, font partie d’une base de données, et il faut savoir qu’on peut avoir plusieurs base de données.DocumentDB

Pour persister une donnée, il suffit de prendre son objet, de le convertir en JSON et d’utiliser le SDK pour créer un nouveau document dans la collection. Comme les bases de données NoSQL sont « schema-free », chaque document peut avoir une structure différente. Par exemple, on pourrait avoir un document qui représente un usager, puis un autre document qui représente un panier d’achat dans la même collection.

Les défis rencontrés

Comme DocumentDB a été publié récemment, celui-ci n’a malheureusement pas beaucoup de documentation à ce jour. Heureusement pour vous, nous avons décidé de vous énumérer quelques problèmes que nous avons vécus et les solutions que nous avons trouvés.

L’ampleur des documents

Chaque collection est limitée par un certain nombre de requêtes par seconde. Autant que cela peut être un désavantage à certains moments, cela devient un avantage au niveau de la flexibilité. Afin de minimiser le nombre de requêtes nécessaire, nous avons découverts qu’avoir le plus petit document possible augmente considérablement la performance des requêtes, et diminue surtout le nombre de requêtes par seconde. Par conséquent, nous avons considéré que chaque document ne devrait pas contenir plus d’un objet agrégat à la fois.

Le partitionnage des données

Au moment d’écrire cet article, chaque collection est limitée à 10GB de stockage. Il faut donc monter soi-même une stratégie de partitionnage des données. Il existe plusieurs stratégies, soit de débordement, de « hashing », par période de temps, etc.

La stratégie la plus simple à implémenter est par débordement. Cette stratégie consiste à ajouter les documents dans la dernière collection créée, et lorsqu’on approche d’un quota, 90% de sa capacité par exemple, alors on crée une nouvelle collection. Voyez un exemple de l’implémentation de Microsoft.

L’impact du mode de connexion

DocumentDB peut utiliser deux types de connexions, soit un mode direct et un mode passerelle. Le mode passerelle est préférable lorsqu’on préfère faire nos requêtes via l’API de DocumentDB. Le mode direct est plutôt utilisé avec le SDK, car il a accès directement aux routes des tables et collections. Par conséquent, il est donc plus rapide.

On peut facilement changer le mode de connexion comme ceci :

Éviter le délai d’attente sur l’ouverture

Par défaut, la première requête est toujours plus longue à exécuter, car DocumentDB doit retrouver la table d’adresse des routes. Afin d’éviter ce délai, on peut tout simplement ouvrir le client dès le démarrage du serveur comme ceci :

Requêtes entièrement asynchrones

Toutes les requêtes effectuées vers DocumentDB avec le SDK C# sont exécutées en mode asynchrone. Pour réussir à utiliser le SDK efficacement, il faut bien comprendre les rudiments des méthodes asynchrones en C#. Cela peut représenter un défi lorsqu’on commence à apprendre DocumentDB, car vous pouvez souffrir de problèmes de deadlocks. Voici des lectures intéressantes MSDN: Asynchronous Programming with Async and Await et Blog Stephen Cleary : Async and Await, afin de mieux comprendre les méthodes asynchrones en C#.

Retourner un grand lot de données

Par défaut, une requête de DocumentDB retourne ses résultats par lot de 100 données. Alors, pour limiter le nombre de voyages, on peut augmenter le nombre de données retournée par voyage.

Idéalement, on veut limiter au maximum le nombre de données en utilisant un système de pagination quelconque. Malheureusement, DocumentDB n’offre pas encore cette possibilité pour l’instant.

Évidemment, nous n’avons pas couvert tous les problèmes que nous avons rencontrés. Au cours des prochaines semaines, nous publierons d’autres articles sur des problèmes plus complexes. Restez à l’affût sur notre blogue pour suivre les avancements de cette technologie!

Impression générale de DocumentDB

DocumentDB est disponible au public depuis près de 6 mois. Malheureusement, il n’est pas encore mature et manque certaines fonctionnalités primordiales. Au moment d’écrire ces lignes, il ne permet pas de pagination (limiter les résultats) et cela devient frustrant lorsqu’on commence à avoir énormément de données. De plus, il n’existe présentement aucune fonction d’agrégat (Sum, Count, Average, Group, etc.).

Malgré ces défauts, Microsoft a fait un travail incroyable pour publier cette nouvelle base de données, et il faut savoir qu’ils font des livraisons très rapidement. Tout de même, cela reste une technologie considérable lors du choix d’infrastructure dans nos projets.

Partagez cette publication

Commentaire (0)

Laisser un commentaire