MongoDB et ElasticSearch

05 juillet 2016 Par Posté dans Expertise

MongoDB et ElasticSearch ont été conçus pour répondre à des besoins très différents. A l’origine, Mongo s’adressait aux problématiques de stockages de données dans un contexte de big data, tandis qu’ElasticSearch (ES) permettait l’indexation et la recherche à l’intérieur des banques de données. Avec le temps, l’évolution de ces deux produits les a rapprochés au point de les retrouver dans des cas d’usages similaires. Cependant, leurs différences de conceptions continuent à avoir des conséquences sur beaucoup de leurs caractéristiques.

 

La flexibilité
MongoDB stocke l’information sous forme d’objets JSON, appelés Documents. Aucun schéma n’est imposé, chaque document peut potentiellement être structurellement différent du précédent. Cette caractéristique apporte une immense flexibilité aux développeurs, aussi bien dans les phases de conception de l’application que dans ses évolutions futures. Cette flexibilité n’existe pas dans ElasticSearch. Si les données sont également stockées sous forme d’objets JSON, ES s’attend à avoir un schéma les décrivant. Et s’il n’est pas fourni, un schéma type est automatiquement créé (avec les risques d’erreurs inhérents) à la réception du premier document. Les documents suivants devront s’y conformer, ou être rejetés. Un ajout dans l’objet JSON est toujours possible après coup, mais une modification s’avère beaucoup plus compliquée. En effet, le schéma est utilisé pour l’indexation des données, et l’indexation ne se fait qu’au moment de leur insertion dans la base. Un changement de schéma va nécessiter une régénération complète de l’index, ce qui équivaut donc à un export/import massif de l’ensemble des données concernées se trouvant dans la base.

 

La rapidité
Les vitesses d’insertion sont comparables, ainsi que le requêtage sur des quantités de données modestes. Cependant, les temps de réponse de MongoDB vont en augmentant avec le volume recherché, là où ElasticSearch reste stable. C’est là que se trouve le revers de la médaille de la flexibilité offerte par MongoDB. Du schéma imposé par ElasticSearch sur les données insérées découle d’une indexation beaucoup plus efficace, dont l’avantage devient apparent dès que les volumes deviennent importants. Cette propriété explique son utilisation dans des contextes se rapprochant de la BI, telle que dans la combinaison de plus en plus populaire ElasticSearch-Logstash-Kibana ou encore ElasticSearch-Curiosity développé par Pages Jaunes.

 

Interconnexion
L’interaction avec ElasticSearch se fait au travers d’une API REST. La sécurité est assurée par un plugin payant. MongoDB dispose d’un contrôle d’accès gérant les utilisateurs et les rôles. Le protocole d’accès lui est propre, mais des drivers existent pour tous les langages courants.

 

Scalabilité
Les deux systèmes sont prévus pour assurer une scalabilité horizontale, permettant ainsi le stockage d’une quantité arbitrairement grande de données. Dans les deux cas, cette scalabilité est assurée d’une part par un mécanisme de sharding (répartition des données sur plusieurs nœuds) et un mécanisme de réplication (copie intégrale des données sur plusieurs nœuds). La construction d’un cluster MongoDB nécessite 3 types de serveurs différents : un contenant la configuration, un autre assurant le routage des requêtes et enfin les serveurs contenant les données. ElasticDB cache cette complexité, chacun des serveurs de données (les nœuds ES) assurant toutes les fonctions.

Dans le cas de MongoDB, l’administrateur de la base doit choisir une clef qui sera utilisée pour la répartition des données sur les différents shards. C’est selon cette clef, qui correspond à un élément commun à tous les documents, que va être décidé le shard de stockage de chaque nouvelle entrée. Ce choix a des répercussions sur l’efficacité et l’équilibre du cluster. Par défaut, ElasticSearch automatise ces choix. La création d’un cluster ES se résume à indiquer le nombre idéal de shards et de réplicats pour un index donné. ES va ensuite les répartir sur les nœuds disponibles, chaque nouveau nœud étant détecté et rajouté au cluster. La mise à l’échelle est donc particulièrement simple à mettre en place et à maintenir.

 

Pour conclure…
Lucenes, sur lequel ElasticSearch repose, ne créé pas de checksum lors de l’écriture d’information sur le disque. L’information peut donc potentiellement être incorrecte une fois mise sur le support de stockage. De plus, beaucoup de manipulations (changement dans l’index, dans le nombre de shards), nécessitent encore la réimportation des données, ce qui peut être une opération lourde pour une application de big data. De l’avis même de l’éditeur, ElasticSearch n’est pas encore prêt à être utilisé comme stockage principal de la donnée. Cependant, ce dernier dispose d’avantages certains dans la recherche d’information à l’intérieur de base de données massive. Mieux vaut donc garder MongoDB pour le rôle de datastore et l’utiliser pour alimenter ElasticSearch avec les données devant être fouillées.

 

Mongo DB ElasticSearch

 

 

 

 

 

 

 

 

 

Laisser un commentaire

Votre adresse email ne sera pas publié