Actualités

[21/06/2017] Smile dans le top 10 des entreprises où il fait bon travailler !

Smile entre dans le classement très fermé des entreprises où il fait bon débuter sa carrière. Un palmarès publié dans Les échos et réalisé par Meilleures-entreprises.com.

[20/06/2017] Smile classé 1er hébergeur en haute disponibilité depuis 3 mois

Depuis début mars, soit 3 mois consécutifs, Smile est à la tête du Classement des Hébergeurs en haute disponibilité, réalisé par ip-label et le Groupe NextRadio TV (01net, BFM, RMC).

[20/06/2017] Smile remporte l'Extending eZ Award !

Lors de l'eZ Conference 2017 qui s'est tenue du 6 au 8 juin, Smile a remporté l'Extending eZ Award.

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

Intégration d'une base MongoDB dans un projet Magento

Sur un grand projet e-commerce à base de Magento, Smile a intégré la base MongoDB pour un gain très important en terme de performances, d'extensibilité, et d'architecture. Nous avons demandé à Aurélien Foucret, expert technique sur le projet, de nous en dire plus.

En premier lieu, pourquoi cette intégration de la base NoSQL MongoDB ?  Quelles sont les limitations que vous cherchiez à adresser ?

Aurélien Foucret : Magento est un produit « LAMP », s'appuyant donc sur la base MySql pour la totalité de sa gestion de données. Comme beaucoup de produits modernes, Magento doit à la fois stocker des données très hétérogènes – un livre ne se représente pas avec les mêmes attributs qu'une télévision  –  et donner de la flexibilité aux utilisateurs pour faire évoluer les caractéristiques produits, les attributs.  Les caractéristiques des produits téléviseurs évoluent dans le temps par exemple avec l'apparition de nouvelles normes ou de nouvelles technologies.

L'une des techniques classiques employée pour répondre à cette problématique sur une base de données relationnelle est de proposer un modèle dit Entity-Attribute-Value ou EAV.  Le principe de cette modélisation est de séparer les données fixes du produit de ses attributs qui sont stockés dans des tables spécifiques (5 tables au total pour Magento).
Ce modèle présente un avantage important par rapport au stockage à plat des données dès lors qu'il s'agit d'opérer la mise à jour du modèle de stockage des produits puisqu'il n'est pas nécessaire de modifier la structure des tables de stockage. Cette opération est en effet très difficile à opérer dès lors que le volume contenu dans une table devient important. Cela rend très clairement le passage à un modèle à plat difficile à envisager.

En contrepartie, le modèle EAV présente un coût important pour certaines opérations basiques.   Ainsi pour obtenir un produit ou une liste de produits, il est nécessaire de procéder à des opérations de jointure assez lourdes pour récupérer l'ensemble des attributs du produit. Sur une base produits dont la volumétrie n'est pas très importante, c'est tout à fait acceptable. Mais dès lors qu'il s'agit de manipuler une base de plusieurs millions de produits le coût de ces opérations devient vite prohibitif.   Sur une base de 5 millions de produits avec une moyenne de 20 attributs produits, on effectuerait des opérations de jointure sur une centaine de millions de lignes.

Un autre aspect important est la perte de performance en écriture sur le catalogue. Si un produit contient une vingtaine d'attributs, il faudra vingt fois plus de requêtes d'insertion, alors que dans un modèle à plat une seule suffirait.

Comme beaucoup, nous sommes arrivés assez naturellement à la conclusion que le modèle EAV était le seul possible dans Magento à périmètre fonctionnel égal mais qu'il s'agissait aussi d'une limite de la solution sur des catalogues de taille très importante.  Du moins, si l'on reste sur une base de données relationnelle classique ...

Et donc, l'utilisation de MongoDB est la solution ?

AF : En effet, le fait de considérer l'utilisation d'une base NoSQL documentaire et plus particulièrement MongoDB est la solution la plus naturelle dès lors que l'on sort des SGDBR.  Notre idée de départ est de considérer l'ensemble des informations produits comme un unique document.
On retrouve ainsi un modèle à plat, dans la mesure où le document est unique. Mais la grande force de MongoDB est qu'il n'est pas nécessaire de modifier la structure de la collection de document pour ajouter ou retirer des champs. Cela permet de combiner les avantages de performances du modèle à plat sans les problèmes de gestion du modèle de données décrit plus avant.

Le modèle obtenu permet de repousser très loin les limites de stockage de produits de Magento. Les gains sont considérables dès lors qu'il s'agit par exemple d'insérer un produit, une seule requête nécessaire, ou de récupérer des produits , les jointures coûteuses sont évitées.

On parle souvent de scalabilité horizontale avec NoSQL (et MongoDB). Mais les gains obtenus ici sont réellement liés à une meilleure modélisation des données plus adaptée à leur usage. A titre d'exemple le temps de synchronisation d'une base produit est amélioré d'un facteur dix environ.

Mais remplacer le stockage des attributs, cela implique-t-il des modifications profondes dans Magento ?

AF : Magento a une architecture très bien pensée, avec en particulier une couche bien identifiée pour gérer l'accès aux données. C'est ce qui nous a permis d'intégrer cette nouvelle gestion des données de manière très ciblée, très propre. Et en particulier, d'être assurés que nous pourrons suivre les versions du produit sans difficultés.

Concrètement, nous avons réécrit principalement la couche de stockage des données produits (Resource Model et Collection) de Magento, soit environ 1000 lignes de code. Quelques modifications des « observers » natifs de moindre importance ont aussi été nécessaires. C'est donc une modification bien maîtrisée, relativement légère au regard des bénéfices obtenus.
Et on garde la compatibilité avec tous les modules existants de Magento, sauf l'import en masse, qui précisément est réécrit pour être en natif MongoDB.

Et quels sont les bénéfices au final ?

AF : Comme cité plus haut, nous gagnons un facteur 10 sur les batchs.  Ceci aussi bien sur les imports que sur les exports, ce qui est fondamental pour diffuser le catalogue efficacement à des partenaires tiers de type comparateurs de prix ou de retargeting.
Nous gagnons aussi en performance sur les accès aux pages catalogue et pages produits par rapport à un Magento natif.  Dans les faits ce gain est à minorer car chez Smile, sur les projets d'envergure, nous avions déjà une pratique spécifique sur les pages catalogue, qui consistait à utiliser le moteur d'indexation et recherche SolR au lieu des accès MySql du produit natif. Les premières versions de Magento n'intégraient pas SolR. C'est à l'occasion du projet Furet du Nord, un grand libraire en ligne, que nous avons intégré le moteur SolR à Magento pour la première fois. Pour la gestion d'un catalogue dépassant le million d'article, c'est une nécessité. Et SolR apporte aussi des fonctions de navigation par facettes et de recherche full-text ultra-performante. Depuis lors, Magento a intégré SolR nativement, mais uniquement pour la recherche.

L'intégration de MongoDB permet en revanche des gains significatifs pour construire plus rapidement l'index SolR. Nous sommes donc sur une stratégie d'intégration des deux technologies.
En outre, de nombreuses parties visibles par le client utilisent des produits sans pour autant bénéficier de SolR. On pensera notamment au panier ou aux wishlists. Ici encore, la base MySql est moins sollicitée sur des opérations complexes et le gain n'est pas négligeable, tant en temps de réponse qu'en capacité d'accueil.
Un autre endroit où l'intégration de MongoDB change la donne, c'est dans l'utilisation du back-office. Sur des bases produits très importantes, on peut gagner un facteur 4 sur la performance du back-office, dans la gestion des produits.
Mais indépendamment des performances et de la capacité d'accueil, la simplicité de l'architecture d'accès aux données est un bénéfice en soi.

Au delà des performances, on gagne sans doute également en extensibilité ?

AF : Oui, c'est une des caractéristiques des bases NoSql que de pouvoir être distribué facilement, et pratiquement sans limites. C'est le cas de MongoDB.  Pour une plateforme standard de e-commerce, une base utilisant un serveur unique peut déjà aller très loin. Mais il serait aisé de la distribuer sur 2 ou 3 serveurs, avec une capacité de traitement augmentant de manière pratiquement linéaire. Dans le cas de Magento, nous ne remplaçons pas la base MySql. Mais nous allégeons tellement sa charge que les limites en extensibilité sont repoussées très loin. On estimait déjà qu'une plateforme Magento standard pouvait distribuer le trafic sur au moins 10 frontaux pour un unique serveur de base de données.  Avec l'intégration MongoDB, on pourrait atteindre certainement 30 à 40 frontaux. Nous avons planifié des tests de charge qui permettront de mieux qualifier cette limite.

Et pourrait-on remplacer radicalement MySql par MongoDB ?  

AF : Non, et ce n'est pas le but. D'une manière générale, les bases NoSql n'ont pas vocation à remplacer les bases relationnelles. Il leur manque en particulier l'intégrité transactionnelle, qui est impérative pour certaines fonctionnalités. C'est bien une utilisation conjointe qui est recommandée. Rappelons que « NoSQL » signifie « Not Only Sql », pas uniquement SQL et non pas « pas de SQL ».

Que dit Magento de ces modifications ?

AF : Dans le cadre du projet cité, des experts de l'Expert Consulting Group (ECG) de Magento ont audité et validé notre intégration. Il s'agissait en particulier de confirmer qu'elle était compatible avec le support « entreprise » de l'éditeur. Il semble aussi que cet axe de développement pourrait intéresser Magento pour être intégré à des versions futures, mais nous n'avons pas d'information particulière sur ce sujet. Du moins au sein de Smile, nous allons proposer le déploiement de MongoDB à Magento sur tous nos déploiements à très forte charge ou intégrant des bases produits de plusieurs millions d'articles. Avec MongoDB, on peut gérer 30 ou 50 millions de produits avec des temps absolument constants.

Avez-vous d'autres astuces pour mettre en place des plateformes Magento à très fortes charges ?  

AF : Entre SolR et MongoDB, venant compléter MySql, on a vraiment ce qui se fait de mieux pour la gestion de données, une vraie Formule 1. Comme je le disais, il n'y a plus guère de limite de capacité, tant en volumétrie qu'en charge.
Il faut ajouter aussi que MongoDB se prête très bien aux traitements batch distribués utilisant l'algorithme MapReduce. Dans le contexte du e-commerce, c'est typiquement le type de traitement dont on a besoin pour faire mouliner par exemple un moteur de recommandations, travaillant sur toutes les statistiques de vente. L'intégration de ce type de technologie ouvre beaucoup de perspectives nouvelles en terme d'usage et représente donc un réel plus au delà du strict aspect technique qui consiste à améliorer les performances.

Enfin, une autre amélioration liée au outils NoSQL que nous avons introduite récemment consiste à remplacer Memcache par Redis dans l'architecture utilisée par Magento. Comme beaucoup d'applications modernes, Magento utilise Memcache pour la gestion des sessions utilisateurs et des caches applicatifs. C'est un outil ultra-performant, dont l'un des plus grands utilisateurs est Facebook.  Mais Memcache n'a pas de persistance, de sorte que l'arrêt d'un serveur peut faire perdre les sessions, et donc les paniers clients.  Redis offre des performances très proche de celle de Memcache mais apporte en plus un stockage persistant. On a donc un gain en termes de robustesse, pour un coût d'intégration très faible. En outre la gestion du cache applicatif par Memcache présentait l'inconvénient de solliciter la base de données pour stocker des données liées à la gestion du cache (les tags). C'est un moyen supplémentaire d'alléger la sollicitation de la base de données,  qui est souvent le seul élément d'architecture non scalable d'une architecture LAMP standard.   

Patrice Bertrand
picto

Commentaires

Soyez la premiere personne à ajouter un commentaire sur cet article.
Ecrire un nouveau commentaire