Table séparée pour les articles ARCHIVE - duplication de #_finder_links comment !

[zafreelance]

Bonjour, voial j'ai une petite idée a faire ...

j'ai un site d'actualité avec des milliers d'articles, j'ai décidé d’abandonner le K2 , alors je me suis retourné vers vers content native de Joomla pour garder l'originalité du CMS maximmu bref

maintenant la question qui se pose à long terme ...

maintenant on sait que les articles sont tous stockés dans la table _content. la question est ici quand je deplace les qlq articles en mode archive ils restent dans la meme table ce qui pose un problème de charge à long terme. esque je peux créer une table séparée pour déplacer les articles archive directement ou automatiquement dans la table _archive par exemple.

aussi une 2 eme question si vous remarquer le principe de duplication des tables _finder_links selon la charge .
esque je peux utiliser ce systeme avec la tables content pour répartir la charge des insertions.

voila, merci j'attend vos suggestions . bonne journée

[jisse03]

Re : Table séparée pour les articles ARCHIVE - duplication de #_finder_links comment

Bonjour,

Sur un serveur MySQL correctement configuré, même de très grosses tables (plusieurs dizaines de gigas) avec des centaines de milliers d'articles ne posent aucun problème de performances.

Par contre, exploser la table content en content + archive poserait le problème des tables pivot et du nombre de requêtes, ce qui provoquerait des ralentissements notables.

Quand à l'organisation du finder, il s'agit de tables hiérarchisées, selon le principe d'un modèle hiérarchique alphanumérique, destiné à optimiser les recherches (terme commençant par A => table linksa, etc...).

[zafreelance]

Re : Table séparée pour les articles ARCHIVE - duplication de #_finder_links comment

Merci de votre reponse mon ami, frenchement je une mauvaise experience avec le mysql version standard, sur K2 apres presq 3 ans d’existence de mon site d'actualité avec un grand nombre d'articles j été obligé de vider ou supprimer les anciens articles pour qu'il fonctionne correctement aussi les tables finder, mais sur K2.

maintenant je ne veux pas répéter l'erreur sauf si j'oblige l'entreprise d'acheter une version pro de MySQL ou etablir des bonne stratégies d'hébergement ( cluster, loadbalancing, ...)

par contre les options : cache, et optimisation sont vraiment important pour ce type;
donc en générale les problèmes des lenteurs sont pas acceptable pour ce genre de sites. voila pkoi je cherche à améliorer le fonctionnement du site.

a votre avis combien ça peut allez la résistance de stockage d'articles dans la table _content ?

merci de votre aide

[jisse03]

Re : Table séparée pour les articles ARCHIVE - duplication de #_finder_links comment

Pour les tailles maximales des tables et le nombre d'enregistrements, la grosse dépendance dépend de la configuration du serveur, en particulier du storage InnoDB (en storage intégré ou en storage multiblocs), des tailles maximales allouées, de l'autorisation ou pas de l'autogrow, etc.

MySQL, bien que plus simple à configurer proprement qu'un Oracle ou un PostgreSQL, n'est quand même pas enfantin dès lors que l'on a besoin d'un stockage important et d'excellentes performances.

Le recours à un serveur SQL dédié est souvent nécessaire (gros sites eCommerce), voire à un MySQL Cluster, avec utilisation du proxy de requêtes (en lieu et place du driver habituel) et du storage engine federated.

La limitation, une fois le tout configuré proprement, est celle de la taille globale du stockage. Et en performances pures, comme avec Oracle, DB2 ou PostgreSQL, la RAM cache d'index et requêtes devient primordiale. Par exemple, en allouant 64 Go de cache requêtes en RAM sur un gros serveur non cluster, on quadruple les performances par rapport à un cache de 32 Go.

Il n'y a donc pas une réponse unique à la problématique, les solutions dépendent du contexte propre à chaque besoin.