Quel est le bon équilibre entre la réutilisation des champs et la création de nouveaux dans le contexte de l'évolutivité des champs?
J'ai lu la phrase suivante sur un site Web:
Au lieu d'ajouter de nouveaux champs à un type de contenu, l'ajout de champs existants est une meilleure option pour réduire la complexité du système et améliorer l'évolutivité.
Et certains doutes surgissent.
Dans le système que nous développons, nous avons la possibilité de réutiliser un champ sur 3 ou 4 types de contenu mais au lieu d'améliorer l'évolutivité comme le dit la phrase citée, je crains que cela ne le diminue, car la table du champ deviendrait plus rapidement un goulot d'étranglement (du moins, c'est mon raisonnement dans ce cas, car toutes les valeurs de ce champ ensemble seraient de quelques millions par an et cela rendrait le tableau trop grand). Êtes-vous d'accord?
Combien de lignes serait un maximum raisonnable à viser lors de l'architecture? De cette façon, nous pourrions décider quand réutiliser les champs et quand en créer de nouveaux (même si la chance de réutiliser est là).
La quantité de données dans un champ n'est généralement pas un problème. Si cela vous inquiète, examinez d'autres plugins de stockage sur le terrain ou écrivez le vôtre. Par exemple MongoDB , qui peut gérer à peu près tout ce que vous y mettez. Il est par exemple utilisé sur http://examiner.com .
Un problème réel est cependant le nombre de champs dont vous disposez. Parce que actuellement dans Drupal 7, la configuration complète des champs de tous les champs , qu'ils soient chargés ou non , est récupéré dans le cache à chaque demande.
J'ai vu des sites avec plus de 250 champs, où le chargement et la désérialisation de la configuration des champs prennent 13 Mo + de mémoire.
Edit: Le cache des informations de champ a été amélioré (voir http://drupal.org/node/104079 pour plus de détails) avec Drupal 7.22, seuls les champs des bundles qui sont affichés sur une certaine page sont chargés à partir du cache et ce sont des entrées de cache distinctes. Cela ne fonctionne que s'il n'y a pas d'appels d'API incorrects qui demandent des instances sur plusieurs bundles.
Je suis totalement d'accord avec berdir. Voici mes expériences avec un projet avec des millions de lignes et 30-40 champs sur certains types de nœuds.
- Le nombre de lignes dans une table de champs n'est pas un gros problème pour les performances de lecture, car tous les champs sont récupérés par clé primaire.
- Le nombre de champs par type de nœud peut rapidement devenir un gros problème de performances lors de l'écriture de nouveaux nœuds. Avoir plus de 30 champs pour un type de nœud se traduit par 60+ instructions INSERT lorsque vous créez un nouveau nœud. Cela prend quelques secondes. Si vous êtes des utilisateurs qui créent beaucoup de données, cela affectera vos performances. Les insertions en vrac de 1000 nœuds prendront près d'une heure. Si vous devez mettre à jour 100'000 nœuds, c'est un gros problème.
- Si vous pensez que le problème du nombre de champs va vous frapper, vous devriez sérieusement penser à écrire votre propre stockage de champs ou tout simplement ne pas utiliser de champs. (Vous pouvez toujours faire fonctionner votre nœud avec des vues avec un effort supplémentaire.)
- Un mot sur MongoDB. C'est un projet très intéressant et j'espère qu'il fera son entrée dans l'olymp des grandes DB. Malheureusement par rapport à la maturité de MySql ou PgSql, c'est un bébé. Soyez prêt à faire face à un produit très jeune.
Si vous êtes vraiment inquiet de ce qui va se passer, je pense qu'une simulation est de mise.
Ouvrez un compte sur Rackspace Cloud, Amazon, Linode, ou n'importe où ailleurs, vous pouvez facilement faire tourner un VPS. Créez deux instances identiques. Installez Drupal sur chacun. Créez des types de contenu factices et configurez les champs d'une manière dans un système et d'une autre manière dans l'autre. Utilisez le module devel pour créer une cargaison de contenu. Ajustez les paramètres de performance pour vous assurer que Drupal est mis en cache selon les besoins. Exécutez mysqltuner et ajustez MySQL sur chaque recommandation. Vérifiez deux fois PHP et les paramètres APC pour que vous ne soyez pas aren 't frapper swap et que vous n'agitez pas le cache APC.
Une fois que vous obtenez une bonne configuration de base pour chacun, commencez à simuler le trafic (à la fois les visiteurs normaux et les mises à jour administratives) avec wget et drush, puis profilez.
Les simulations ne sont jamais parfaites, mais elles peuvent vous faire avancer dans la bonne direction.
une autre astuce: avoir beaucoup de champs entraînera également des problèmes avec de nombreux modules différents. L'interface graphique Token, par exemple, retardera votre navigateur de quelques minutes si vous essayez de modifier les alias d'URL par exemple. Ce comportement peut être vu sur toutes les pages où le jeton sera chargé et affiché (y compris devel - dpm () etc.)
Il n'y a aucun avantage en termes de performances à diviser ces données sur plusieurs tables lors de l'utilisation d'InnoDB (MyISAM est différent en raison du verrouillage des tables). Donc - si vous savez que vous aurez beaucoup de types de contenu similaires avec des champs similaires (dont les configurations seront également les mêmes, peut-être différer dans l'étiquetage uniquement) réutilisez vos champs!
Cela peut également faciliter la création de modèles en raison d'attributs de noeud similaires.
Un problème avec l'évolutivité des champs dans l'utilisation des index sur chaque champ de table unique dans chaque champ de la table créée. L'index clusterisé de clé primaire est un composite de la plupart des champs, puis il a créé des index distincts sur chaque individu de champ. Les index créent une tonne d'écritures de surcharge pour la base de données et, dans la plupart des cas, ne sont jamais utilisés.
Pour partager mon histoire, nous utilisons Drupal Commerce et avons environ 40 champs dans nos variantes de produits (Sku), puis 460 autres (oui, fous) dans notre affichage de produit. Nous avons eu une comparaison de produits vues qui examineraient tous ces champs. Sans mise en cache, certains chargements de page pourraient prendre jusqu'à une minute!
Cependant, cela a fonctionné. Si vous avez utilisé la mise en cache et le vernis, le temps d'attente de l'utilisateur n'était pas si mauvais.
Le principal problème que nous avons rencontré avec autant de champs est avec Display Suite, car cela deviendrait très lent (parfois non réactif) si nous essayions de réorganiser ou de déplacer un champ.
Heureusement, nous avons décidé de re-factoriser un peu nos produits afin que nous puissions, espérons-le, obtenir notre nombre maximal de champs dans la gamme 200-250 pour nos produits les plus complexes (nous sommes dans l'instrumentation scientifique, donc des mesures et des spécifications complexes sont nécessaires) .
C'est une question intéressante. J'y ai déjà pensé, parfois la réutilisation d'un champ peut être pratique pour ne pas avoir des tas de champs similaires qui traînent, mais il semble stupide d'avoir un certain type de contenu devant choisir parmi une grande quantité de données que nous know n'est pas censé être retourné dans le résultat.
J'aurais besoin d'un peu plus d'informations sur le projet pour vous conseiller sur les meilleures pratiques de mise à l'échelle. Quel est le trafic attendu, combien de ces utilisateurs doivent être connectés, etc.? Par exemple, si tout le trafic, à l'exception de celui de vos utilisateurs administrateurs, n'est pas authentifié et mis en cache de manière anonyme
Jusqu'à présent, j'ai toujours réutilisé des champs, mais j'envisage maintenant d'utiliser des champs uniques par type de nœud pour un nouveau projet. En fait, je veux garder tout bien séparé (champs, vues, règles, contextes, etc.) pour chaque ensemble d'entités. Cela a donc soulevé la question de l'évolutivité qui m'a conduit ici. Je suis réconforté par l'édition de Berdir (Le cache d'informations sur le terrain a été amélioré (voir http://drupal.org/node/104079 pour plus de détails) avec Drupal 7.22 , seuls les champs des ensembles qui sont affichés sur une certaine page sont chargés à partir du cache et ce sont des entrées de cache distinctes. Cela ne fonctionne que s'il n'y a pas d'appels d'API incorrects qui demandent des instances sur plusieurs ensembles).
Je veux juste souligner qu'il y a un module très intéressant que j'utilise depuis des mois sur plusieurs sites complexes: https://www.drupal.org/project/render_cache . C'est l'un de ces joyaux cachés à mon avis.
Comme il est indiqué sur la page du projet, la partie commentaires est actuellement utilisée sur D.O. lui-même.
Donc, avec tout cela à l'esprit, cela tournerait-il le consensus en faveur de domaines séparés? La mise en garde mentionnée à propos de DS est toujours une erreur, cependant. C'est très ennuyeux la façon dont il enregistre via ajax au lieu, par exemple, de la façon dont l'interface d'administration du bloc central gère les réorganisations. Je me sens c'est un problème ds, cependant ...