- scalling horizontal
- recherche full scan
- performance
Je rappelle que le NO veut dire Not Only pour exprimer le fait qu’il existe d’autres alternatives au relationnel. Mais le NOSql ne veut pas dire que ces solutions viennent remplacer les SGBD classiques. Elles répondent mieux à certains use case mais pas à tous.
La session était animée par deux developer advocates David Pilato pour le moteur de recherche Full Text et Tugdual Grall pour la base Nosql Couchbase.
L’application initiale était une application Web MVC utilisant toutes les couches applicatives classiques. Le but de la refonte était de transformer la partie serveur pour mettre à disposition des services REST/Json accessibles depuis des clients web ou mobile (use case qui se multiplie aujourd’hui avec l’avènement des smartphones et des tablettes).
Le premier avantage qui apparaît avec Couchbase est que cette base orientée document stocke des données au format JSON. Les données arrivant peuvent donc directement être sérialisées en base de données. La présentation était incrémentale et montrait un rapide use case montrant l’intérêt du schéma less des modèles nosql. En très peu de développement vous pouvez rapidement mettre à jour votre structure en base de données sans avoir à faire intervenir de DBA.
Dans une application CRUD standard les fonctionnalités de recherche sont assez limitées. Proposer des recherches intelligentes en précisant une partie de plusieurs champs, placés dans n’importe quel ordre peut vite compliquer les requêtes SQL. C’est là qu’un moteur d’indexation comme ElasticSearch montre toute sa puissance et vous permet de mettre à disposition des utilisateurs des fonctionnalités de recherches évoluées via de simples appels REST. Aujourd’hui il est difficile de restreindre les capacités de recherche dans une application alors que toutes les personnes utilisent chaque jour de leur côté des moteurs de recherche comme Google.
La présentation était bien ficelée et axée sur la facilité de développement et les performances de la solution (1 million de données). Il manquait peut être une partie sur le failover mais je trouve que c’était une très bonne présentation d’introduction qui montre que Couchbase et ElasticSearch ne sont pas concurrents et sont de bonnes réponses à des problématiques d’architecture WOA facilement scalable
Le premier avantage qui apparaît avec Couchbase est que cette base orientée document stocke des données au format JSON. Les données arrivant peuvent donc directement être sérialisées en base de données. La présentation était incrémentale et montrait un rapide use case montrant l’intérêt du schéma less des modèles nosql. En très peu de développement vous pouvez rapidement mettre à jour votre structure en base de données sans avoir à faire intervenir de DBA.
Dans une application CRUD standard les fonctionnalités de recherche sont assez limitées. Proposer des recherches intelligentes en précisant une partie de plusieurs champs, placés dans n’importe quel ordre peut vite compliquer les requêtes SQL. C’est là qu’un moteur d’indexation comme ElasticSearch montre toute sa puissance et vous permet de mettre à disposition des utilisateurs des fonctionnalités de recherches évoluées via de simples appels REST. Aujourd’hui il est difficile de restreindre les capacités de recherche dans une application alors que toutes les personnes utilisent chaque jour de leur côté des moteurs de recherche comme Google.
La présentation était bien ficelée et axée sur la facilité de développement et les performances de la solution (1 million de données). Il manquait peut être une partie sur le failover mais je trouve que c’était une très bonne présentation d’introduction qui montre que Couchbase et ElasticSearch ne sont pas concurrents et sont de bonnes réponses à des problématiques d’architecture WOA facilement scalable
Merci à Arthur Noseda pour sa relecture
Aucun commentaire:
Enregistrer un commentaire
Remarque : Seul un membre de ce blog est autorisé à enregistrer un commentaire.