Le NoSQL: une autre approche pour concevoir avec les bases de données

Le NoSQL permet d’offrir de nouveaux outils et d’automatiser un grand nombre de tâches au moyen d’un outil tel que CBX.

De surcroît, il offre la possibilité de penser totalement différemment les solutions des problèmes tandis que le relationnel est souvent inadapté, voire toujours inadapté au modèle objet.

Se trouve ci-dessous deux exemples d’approches de réponses possibles à des enjeux courants.

L’enjeu des transactions

En NoSQL, il n’y a pas de verrouillage de la base réseau lors d’une transaction d’écriture, et il peut donc y avoir des cas particuliers de conflits de versions lors de l’écriture de données.

Dans le cas général, une base relationnelle classique verrouille la base systématiquement, ce qui rend impossible son usage à grande échelle. Avec le NoSQL,  l’usage d’une base avec un cluster de serveurs suffisamment bien dimensionné ne provoquera pas de conflits dans le cas général. Restera des cas particuliers de conflits à traiter par le code métier.

Plus encore, il sera nécessaire de penser différemment la conception des bases.

Par exemple, pour un système de réservation d’hôtels sur un territoire tel que celui des Etats-Unis ou de l’Europe, il est nécessaire d’avoir une conception alternative en NoSQL au système d’allocation des chambres. Si le choix se fait de continuer avec fonctionner avec des compteurs sur les nombres de chambres libres, des problèmes inextricables se posent et sont de nature à remettre en cause la viabilité du projet.

Un principe de solutions NoSQL que Wyje a eu l’occasion de présenter est de changer la granularité des accès, et d’avoir une entrée dans la base pour chaque chambre. De la manière que si un vendeur de livre ne créait une entrée dans sa base pour chaque livre plutôt que d’avoir un compteur qui nécessairement sera accéder de manière concurrente. Les accès concurrents ne sont donc plus systématique, même s’il est vrai, cela n’est pas complètement suffisant et s’améliore ci-dessous par la résolution d’un problème plus ennuyeux encore.

Par contre, cerise sur le gâteau, c’est le MapReduce qui se charge de fournir automatiquement les valeurs des compteurs.

La question de la latence et l’exemple d’un système de réservation hôtelière

Sur un territoire comme les Etats-Unis, un second problème se pose: les distances entre l’Est et l’Ouest sont telles que pour assurer un temps de transaction suffisamment faible, il devient impossible d’utiliser un seul serveur. Deux serveurs sur les côtes Est et Ouest sont nécessaires pour répondre aux enjeux de la latence. Reste à savoir comment faire logiciellement pour qu’ils puissent travailler en harmonie.

Une fois de plus, si l’on se contente de considérer cet enjeu de manière technique, on se dirige directement vers une nouvelle usine à gaz. En réalité, ce type de problème peut être vu comme une opportunité d’une réponse plus globale à l’enjeu métier qui se pose pour la réservation de chambres.

Si l’on considère les enjeux suivants:

• réserver une chambre à l’avance dans des conditions favorables doit être simple et rapide: c’est le (ou un) cas général
• lorsque un hôtel n’a presque plus de chambres disponibles, il faut pouvoir gérer correctement ce cas particulier y compris lorsqu’il y a des réservations effectuées depuis deux extrémités opposées du pays
• en cas d’affluence, il faut pouvoir gérer les désistements afin de contenter le plus grand nombre de clients possible

L’idée consiste à instaurer des quotas de place pour les deux serveurs ainsi que chaque hôtel en fonction des statistiques sur les lieux de réservations (sur place ou par téléphone directement à l’hôtel, côté Est, côte Ouest). Pour symboliser simplement ce principe auprès du client final, Wyje donne l’idée d’utiliser de s’inspirer de la signalisation routière pour les feux:

• Feu vert: la réservation est effectuée parce qu’il reste de la place, soit dans le quota de l’hôtel ou le dans du serveur considéré.
• Feu orange: la demande de réservation est prise en compte et la réponse sera donnée dès que possible car il ne reste plus de place dans  le quota considéré et le serveur correspondant s’adresse donc à un second serveur, celui de la côte opposée ou celui de l’hôtel. S’il ne reste de place nulle part, le client peut être inscrit ou non en liste d’attente en fonction des statistiques et du calcul de probabilité qui s’en suit. Par ailleurs, il se peut que l’hôtel soit déconnecté ou même que l’un des serveurs ne fonctionne pas en raison d’une panne exceptionnelle.
• Feu rouge: il n’y a plus de places disponibles et la probabilité d’en avoir une qui se libère ne peut être considéré ou si c’est le cas, d’autres personnes sont déjà en liste d’attente et la probabilité d’une n-ème place supplémentaire qui se libère ne peut être raisonnablement prise en compte.

De cette manière, avec ce principe, le cas général est simple et performant, et une solution est trouvée pour les différents cas particuliers:

• L‘hôtel peut directement réserver ces chambres même il a un problème avec sa Box le reliant au réseau Internet (qui n’a pas connu ce problème ?)
• Dans le cas où l’on ne sait pas s’il reste des places disponibles soit parce qu’il faut joindre un autre serveur ou attendre un désistement, un feu Orange s’affiche et le temps de réponse pour le client peut être estimé à quelques secondes s’il s’agit simplement d’attendre la réponse d’un autre serveur, ou à une durée qui peut s’attendre sur plusieurs jours si la possibilité d’un désistement peut être espérée. Grâce à une application sur portable fonctionnant avec Couchbase Lite en réplication partielle, le client est alors informé au plus tôt et peut confirmer sa réservation.

Publicité