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: , , ,