Retour sur la présentation Assurer la scalabilité d’un moteur de recherche pour des milliers de magasins en ligne par Roudy Khoury et Aline Paponaud à ElasticON 2023
Nous avons présenté l’année dernière la version anglaise de ce talk à Berlin Buzzwords. Pour cette année, nous avons participé le 8 mars à la conférence ElasticON Global 2023. A cette occasion, nous avons présenté notre solution de moteur de recherche pour gérer un grand nombre de magasins en ligne. C’était une occasion pour généraliser et mettre à jour la présentation, et aussi partager notre expérience en français.
Les achats en ligne ont été une opportunité pour certains magasins e-commerce pendant la crise du Covid-19. Mais pour presque toutes les entreprises, cela a apporté une multitude de nouveaux défis. Aujourd’hui presque tous les magasins physiques veulent aller en ligne.
En ligne, le moteur de recherche joue un rôle très important dans le succès du magasins e-commerce. Donc il y a des fonctionnalités qui sont attendus du moteur de recherche :
Quand un magasin veut partir en ligne, il va avoir besoin de gérer beaucoup de données. Ces données peuvent être sous plusieurs formes : dans des fichiers, dans une base de données, ou bien obtenu via des streams de différentes sources.
Il peut y avoir des niveaux de maturité différents entre les données des magasins, les données peuvent varier d’un magasin à un autre, ils sont hétérogènes et ils viennent de nombreuses sources. Donc il faut construire la plateforme du moteur de recherche au-dessus de ça. Il faut gérer toutes les complexités qui viennent des données, les masquer et les présenter d’une façon propre.
Pour gérer les données dans Elasticsearch, il y a plusieurs idées. Comme il y a des spécificités pour les offres de chaque magasin, par exemple des promotions qui existe dans un magasin mais pas dans un autre, la première idée qui vient en tête c’est d’avoir un gros index avec tous les données des produits et des offres dedans, et dupliquées par magasins.
Ça pourrait être une bonne solution puisque cette approche est compacte, unitaire et dans laquelle le cluster state reste petit, mais il y a aussi une autre idée. On peut créer un index avec les références des produits, c’est-à-dire les données produits qui ne bougent pas entre un magasin et un autre, et puis tous les offres vont aller dans des index séparés par des magasins, un index par magasins Dans ce cas, nous allons avoir un modèle qui ressemble à un modèle de donnée relationnelle.
Cependant, il y a des inconvénients :
Ce que nous avons fait pour résoudre ces points, c’est que nous avons mis en place un index par magasins.
Dans l’index magasins, on store tous les produits et toutes les offres pour ce magasin avec la configuration. Dans ce cas, il y a aura des duplications car il y a des éléments communs dans les données pour plusieurs magasins. Puisque nous avons un index par magasin, on peut vraiment faire un fine tuning sur chaque magasin Dans ce cas :
Chaque personne qui a réussi à mettre son magasin en ligne va être en directe compétition avec les big players (Amazon, Rakuten, etc) Le moteur de recherche va pouvoir remonter les produits des magasins et s’il y en a pas, il peut remonter des produits de marketplace. Cela peut être un 3rd party qui met à disposition ses produits avec des options de livraisons. Donc la recherche va inclure les magasins physiques ainsi que la marketplace et l’idée c’est que le moteur de recherche cache ces complexités.
Il peut y avoir des milliers de produits des magasins physiques et des millions de produits marketplace. Puisque les produits marketplace ne vont pas avoir des spécificités, nous pouvons les regrouper dans un seul index.
Il reste un problème à résoudre : les produits n’ont pas les même type ou structure de données. Il peut y avoir des produits alimentaires et non alimentaires qui n’ont pas forcément la même structure et champs. Donc, il faut une sorte d’intelligence lors de l’indexation pour mutualiser ça. Pour cela, nous avons proposé un schéma commun pour les données produits. Nous allons préparer nos données en amont avant l’indexation pour avoir une structure bien définie, et de cette façon, la recherche va pouvoir fonctionner sur plusieurs index en même temps, marketplace et magasin.
Pour pouvoir assurer la scalabilité de notre moteur de recherche, il faut quelques points à garantir :
Un quick view sur une telle solution
Comme il y a beaucoup d’index dance cas, le cluster state peut devenir grand rapidement. Donc, nous avons besoin d’être sur du multi cluster.
Nous avons créé plusieurs clusters sur lesquels les indexes sont repartis et on duplique les index communs comme celui de marketplace. Et donc nous aurons besoin d’un router qui va avoir une table contenant l’info sur quel cluster il est chaque magasin.
Des points qu’il faut prendre en considération pour le monitorer le moteur de recherche :
Pour conclure voici une checklist qu’il faut prendre en considération pour réussir à construire son moteur de recherche e-commerce :