mar 31

La dernière version de Magento est sortie cette nuit et avec elle arrive l’option tant attendue : le Flat Catalog!

Celle-ci a été annoncée par Varien comme salvatrice pour les performances de notre outil e-commerce préféré (le site annonce un bénéfice de 40% sur le temps de chargement des pages en front office et sur l’utilisation de la mémoire).

Concrètement, que se cache-t-il vraiment derrière cette option « magique » et quel impact aura-t-elle sur les prochains projets construits sur la base de cette version?

Avant toute chose, rappelons que Magento repose actuellement sur un modèle de données de type « EAV » (Entity-Attribute-Value). Ce qu’il faut comprendre c’est qu’un objet « Produit » dans Magento n’est pas stocké dans une seule table mais éclaté dans un ensemble de tables en fonction des attributs de notre produit. Cette complexification du modèle de données se justifie en grande partie par la souplesse que propose Magento dans le paramétrage de nouvelles caractéristiques pour un produit.

Mais cette souplesse a donc un coût puisqu’il multiplie de manière importante le nombre de requêtes effectués en base pour un seul produit. On touche donc très vite aux limites de ce modèle dès lors qu’on travaille avec un catalogue important (plus d’une dizaine de millier de références). Varien a donc annoncé en début d’année qu’ils proposeraient une simplification de ce modèle sous forme d’une option librement activable depuis le back office pour permettre de basculer vers un modèle de données « à plat ».

En regardant de plus près, cette option est un peu plus subtile que ce à quoi on pouvait s’attendre: une fois le mode ‘flat catalog’ activé dans l’administration, on se retrouve finalement avec deux catalogues: un pour le backoffice, et un pour le front:

  • celui du backoffice reste le catalogue EAV tel qu’il existe dans la 1.2
  • le front utilise des nouvelles tables catalog_category_flat et catalog_product_flat
  • il y a une synchronisation type maître-esclave entre le catalogue backoffice et celui du front

Finalement, le « flat catalog » du front est en réalité une sorte de table de cache pour le vrai catalogue qui reste en EAV.

Les avantages de ce fonctionnement:

  • la migration est bien plus simple puisqu’en réalité le format de la base n’a pas vraiment changé (les tables _flat sont générées à la demande depuis le backoffice)
  • on peut imaginer facilement avoir une base de données front avec les tables _flat côté frontoffice, séparées physiquement de la base de backoffice, avec le moteur Federated de MySQL qui permet de présenter plusieurs bases de données comme en étant une seule aux applications. De ce fait, la charge sur le front n’impacte pas le back et inversement

Les inconvénients:

  • avec des volumétries très élevées, (certains) écrans du backoffice vont être très lents puisqu’ils continueront à utiliser le système EAV
  • les imports devront continuer à se faire dans les tables EAV, d’où une lenteur au moment de l’import (à nuancer: si les données importées ne sont pas destinées à être utilisées dans le backoffice, il est peut être possible de les importer directement dans les tables _flat du front)

Nos premiers tests sur la base de ce nouveau modèle et d’un catalogue de plus d’un million de produits devraient désormais nous fixer assez rapidement sur la pertinence de cette fonctionnalité…

A suivre donc!

écrit par Frédéric de Gombert \\ tags: , , ,


4 commentaires sur “Flat Catalog dans Magento 1.3 – Premières impressions!”

  1. 1. Luc Dit :

    Salut,

    Ça a l’air pas mal comme nouvelle fonctionnalité ! Mais je n’ai pas trouvé dans le back-office l’endroit où l’activer ?

    Dans les Release Notes, on peut aussi lire :
    Added support for customer file upload and date/time/datetime custom options (que j’arriverai à traduire « Ajout du téléchargement de fichier pour les clients et date/heure/date-heure dans les options personnalisables).
    Bien que je comprenne la dernière partie, j’ai plus de mal avec le début : l’ajout d’un champ d’upload pour les clients !?
    Ç’est en rapport avec les produits téléchargeables ?
    Ou bien c’est plutôt pour permettre aux client de pourvoir envoyer des fichiers à la boutique ?
    Cette dernière option me serait grandement utile (je suis en train de finir une boutique de digigraphies, et le client souhaiterait offrir la possibilité aux utilisateurs de pouvoir faire imprimer directement leurs images!). Ça tomberait pile poil si je puis dire ;-) !

  2. 2. Gabriiiel Dit :

    Merci pour ce retour Frédéric, j’ai mis un lien sur Fragento de cet article !

    @ Luc : en backend, ça s’active dans la section de gestion du cache, puis dans la configuration du frontend catalog.

    Pour les options persos c’est effectivement la possibilité aux utilisateurs d’uploader des fichiers pour customiser le produit.

    Tu as le détail de la procédure et toute l’analyse fonctionnelle de la 1.3 sur http://www.fragento.org/Actualite/Magento/magento-130-est-sortie.html

    :)

  3. 3. Gilles Nollet Dit :

    Un sujet de plus pour le bargento :-)
    A voir l’impact sur un upgrade de version.
    En tout cas, si ça améliore de 40% l’affichage du front, ça peut être intéressant.

  4. 4. Olivier DASINI Dit :

    Bonjour,
    Merci pour ces explications claires.

    Par contre j’ai un point de désaccord avec le 2ème point de ta partie avantage avec des tables en FEDERATED.
    * Les tables FEDERATED sont en quelques sorte des vues. Mettre des tables dans ce format sur le front ne diminuera ni la charge, ni l’impact sur le backoffice
    * il faut de plus rajouter le coût lié au coté remote des tables du front, ce qui n’est pas très bon pour les perfs.
    Pour résumer je ne pense pas que FEDERATED soit adapté pour ce type d’utilisation. :)
    Par contre est il possible d’envisager un script de réplication des données du back vers le front ?
    Ce script s’exécuterai pendant des heures de moindres activités. Par contre l’ajout d’un produit ne serai pas vu en temps réel sur le front

Poster une réponse