Quel est le bon équilibre entre la réutilisation de champs et la création de nouveaux champs 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 quelques doutes surgissent.

Dans le système que nous développons, nous avons la possibilité de réutiliser un champ dans 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 le tableau du champ deviendrait plus rapidement un goulot d'étranglement. (du moins c'est mon raisonnement dans ce cas, car toutes les valeurs de ce domaine réunies seraient de quelques millions par an et cela rendrait le tableau trop volumineux). Ê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 des champs et quand en créer de nouveaux (même si la possibilité de les réutiliser existe).

La quantité de données dans un champ ne pose généralement pas de problème. Si cela vous inquiète, cherchez des plug-ins de stockage alternatifs ou écrivez les vôtres. Par exemple, MongoDB , qui peut traiter à 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 que vous avez. Dans la version actuelle de Drupal 7, la configuration complète de tous les champs, qu'ils soient chargés ou non, est extraite du cache à chaque requête.

J'ai vu des sites avec plus de 250 champs, où charger et désérialiser la configuration de champs prend 13 Mo + en mémoire.

Edit: le cache d’informations sur les champs a été amélioré (voir http://drupal.org/node/1040790 pour plus de détails) avec Drupal 7.22, seuls les champs des ensembles affichés sur une certaine page sont chargés à partir du cache et entrées de cache séparées. Cela ne fonctionne que s'il n'y a pas d'appels d'API erronés qui demandent des instances sur plusieurs bundles.

Je suis totalement d'accord avec berdir. Voici mon expérience avec un projet avec des millions de lignes et 30 à 40 champs sur certains types de nœuds.

1. 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 extraits par la clé primaire.
2. Le nombre de champs par type de nœud peut rapidement dégénérer en gros problèmes de performances lors de l'écriture de nouveaux nœuds. Avoir plus de 30 champs pour un type de nœud donne plus de 60 instructions INSERT lorsque vous créez un nouveau nœud. Cela prend quelques secondes à compléter. Si vous créez beaucoup de données, vos performances en souffriront. Les insertions en bloc de 1 000 nœuds prendront presque une heure. Si vous devez mettre à jour 100 000 nœuds, c'est un gros problème.
3. Si vous pensez que le problème de nombre de champs va vous toucher, vous devriez sérieusement songer à écrire votre propre espace de stockage ou simplement ne pas utiliser de champs. (Vous pouvez toujours faire en sorte que votre noeud utilise des vues avec un effort supplémentaire.)
4. Un mot sur MongoDB. C'est un projet très intéressant et j'espère qu'il fera partie de l'olympique des grandes DB. Malheureusement, comparé à la maturité de MySql ou de PgSql, c'est un bébé. Soyez prêt à faire face à un très jeune produit.

Si vous vous inquiétez vraiment de ce qui va arriver, alors je pense qu'une simulation est en ordre.

Obtenez un compte sur Rackspace Cloud, Amazon, Linode ou ailleurs, vous pouvez facilement créer un VPS. Faites deux instances identiques. Installez Drupal sur chacun. Créez des types de contenu factice et configurez les champs d'une manière dans un système et d'une autre dans l'autre. Utilisez le module de développement pour créer un chargement de contenu. Ajustez les paramètres de performance pour vous assurer que Drupal met en cache si nécessaire. Exécutez mysqltuner et ajustez MySQL sur chacune des recommandations. Vérifiez deux fois les paramètres PHP et APC afin de ne pas frapper le swap et de ne pas vider le cache APC.

Une fois que vous obtenez une bonne configuration de base pour chacun, commencez à simuler le trafic (visiteurs normaux et 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.

Un problème d’évolutivité dans les champs lors de l’utilisation d’index sur chaque champ de table dans chaque champ créé dans la table. L'index en cluster de clé primaire est un composite de la plupart des champs, puis il a créé des index distincts sur chaque champ. Les index créent une tonne d'écritures supplémentaires pour la base de données et, dans la plupart des cas, ne sont jamais utilisés.

Un autre conseil: avoir un grand nombre de champs causera également des problèmes avec de nombreux modules différents. L’interface graphique de jetons, par exemple, retardera votre navigateur pendant quelques minutes si vous essayez d’éditer des alias d’URL, par exemple. Ce comportement est visible sur toutes les pages où le jeton sera chargé et affiché (y compris devel - dpm (), etc.).

Il n’ya aucun avantage en termes de performances à fractionner ces données entre plusieurs tables lorsqu’on utilise InnoDB (MyISAM est différent en raison du verrouillage de la table). Donc, si vous savez que vous aurez beaucoup de types de contenu similaires avec des champs similaires (les configurations seront également identiques, peut-être différeront-elles par leur étiquetage uniquement), réutilisez vos champs!

Cela pourrait également faciliter la création de modèles en raison d'attributs de nœud similaires.

Tout en partageant mon histoire, nous utilisons Drupal Commerce et avons environ 40 champs dans nos variantes de produits (sku), puis 460 autres (oui, fou) dans notre affichage des produits. Nous avons eu des comparaisons de produits qui porteraient sur tous ces domaines. Sans la mise en cache, le chargement de certaines pages peut prendre jusqu'à une minute!

Cependant, cela a fonctionné. Si vous utilisiez la mise en cache et Varnish, le temps d'attente des utilisateurs n'était pas si mauvais.

Le principal problème que nous avons rencontré avec tant de champs concerne 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 retarifier un peu nos produits afin que nous puissions espérer avoir notre nombre maximum de champs dans la gamme 200-250 pour nos produits les plus complexes (nous sommes en instrumentation scientifique, des mesures et spécifications précises sont donc nécessaires). .

C'est une question intéressante. J'ai déjà pensé à cela, parfois, réutiliser un champ peut être pratique pour ne pas avoir des charges de champs similaires "traîner", mais il semble idiot de faire en sorte qu'un certain type de contenu doive sélectionner parmi une grande quantité de données savoir n'est pas destiné à ê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 en matière de dimensionnement. 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é les champs, mais j'envisage maintenant d'utiliser des champs uniques par type de nœud pour un nouveau projet. En fait, je veux que tout soit bien séparé (champs, vues, règles, contextes, etc.) pour chaque groupe d'entités. Cela a donc soulevé la question de l'évolutivité qui m'a amené ici. Je suis rassuré par l'édition de Berdir (le cache d'informations de champ a été amélioré ( pour plus de détails, voir http://drupal.org/node/1040790 ) avec Drupal 7.22, seuls les champs des ensembles affichés sur une certaine page sont chargés à partir de le cache et leurs entrées de cache distinctes. Cela ne fonctionne que s'il n'y a pas d'appels d'API erronés qui demandent des instances sur plusieurs bundles).

Je tiens simplement à souligner qu’il existe 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 un de ces joyaux cachés à mon avis.

Comme il est indiqué sur la page du projet, la partie commentaires est en fait utilisée sur DO lui-même.

Alors, avec tout cela à l'esprit, cela tournerait-il le consensus en faveur de champs séparés? La mise en garde à propos de DS est toujours une déception, cependant. C’est super agaçant de savoir comment il enregistre via ajax au lieu, par exemple, de la façon dont l’interface d’administration des blocs principaux gère les commandes. Je pense que cest un problème ds, cependant ...

Selon ma suggestion, utiliser les mêmes champs dans des types de contenu distincts est une bonne idée. Parce que cela améliorera les performances de votre site. Dans Drupal 7, lorsque vous utilisez cette opération, l’utilisation de champs identiques dans le type de contenu est vraiment utile pour votre site Drupal7.