Bonsoir,

Pour infos les tables obèses impactent fortement les performances également. En effet elles génèrent des volumétries creuses et posent des problèmes d'indexation important (démultiplication des besoins d'indexation, probabilité qu'un index couvrant suffise à répondre à lui seul à la requête est inexistante ou presque, etc...) pour l'essentiel.
Après le débat exposé plus haut (noSQL vs SGBDR) est un autre débat...

++

[quote]il faut un système de pile, ce que tu cherches c'est des MOM (Middleware Oriented Messages)
après si tu utilises eleasticsearch tu peux p'tet voir pour l'utiliser comme ça. [/quote]

Ok, je viens de jeter un coup d'oeil derrière RabbitMQ dont j'ai déjà entendu parler. Le principe, c'est un fonctionnement par socket je crois.

[quote]Par contre ça vaêtre sympa les accès réseau et l'appli qui ralentis dès que tu clic quelques part[/quote]

En fait, il n'y a pas tant de clics que ça, les clics sont ciblés sur des actions bien précises (histoire de contrôler quels boutons ou liens sont utilisés sur quelques pages). Ca représente une 50 d'actions tout au plus. En simultané, ca doit pouvoir se gérer car petite base d'utilisateurs.

Je vais tenter un fonctionnement par requête ajax, et si je trouve qu'il ya trop de latence, je réfléchirais la solution avec les MOM.
Merci pour ton aide moogli :)

[quote]
C'est intéressant ça, et c'est facile à mettre en place ?
[/quote]
ça dépend :)

il faut un système de pile, ce que tu cherches c'est des MOM (Middleware Oriented Messages)
après si tu utilises eleasticsearch tu peux p'tet voir pour l'utiliser comme ça.
Par contre ça vaêtre sympa les accès réseau et l'appli qui ralentis dès que tu clic quelques part ;)

@+

[quote]heu comment dire, des tables d'historique ?, 52 tables enplus par an, ça va chiant à utiliser. [/quote]
Pas autant ;) Je pensais à une table par an, j'estime à un peu moins d'1M d'enregistrements par an.

[quote]https://www.elastic.co/fr/products/elasticsearch
y a même un truc pour php
https://www.elastic.co/guide/en/elastic ... index.html

en gros c'est une base nosql qui expose un api rest pour communiquer avec. du coup du json et des appel réseau pour faire la chose.
si tu n'as pas plusieurs nœuds les perfs seront (grosso modo) équivalentes à une base de données si tu en a plusieurs les perfs seront meilleurs.

ensuite tu pourras faire une ihm pour fouiller la dedans qui n'aura rien a voir avec l'appli "monitorée" (tu va même pouvoir y ajouter le monitoring d'autre appli c'est cool ;)~ )[/quote]

Bon, là je crois qu'il faut que j'aille étudier un peu tout ça, je ne connais pas suffisamment Elastic Search...

[quote]ensuite le plus pénalisant pour toi c'est pas vraiment le stockage c'est comment tu va y fourrer les choses.
car que cela soit du nosql, du sgbdr du fichier etc chaque requête va ralentir le système. Passe n'importe qu'elle appli en debug, avec des logs conséquents tu dégrades les perfs. [/quote]
Je pensais faire une requête Ajax pour chaque insertion de log, du coup oui les perfs risquent d'être dégradées, mais ce n'est pas bloquant je pense. Après, il n'y a pas des milliers d'utilisateurs par jour non plus sur cette appli.

[quote]C'est pour cela qu'il existe des système intermédiaire : les piles.
c'est des systèmes non bloquant tu balances ton infos dedans et dès que la pile peu elle le traite. Cela permet d'éviter de bloquer l'appli en attente d'écriture on d'un retour quelconque (la tu bennes sans même savoir si ça se passe rien c'est rapide c'est tout). bon la du coup ça commence à monter l'infra ;)[/quote]

C'est intéressant ça, et c'est facile à mettre en place ?

[quote]
au final ce qu'il faut bien voir c'est le besoin et que tu va en faire car logguer un max c'est bien mais couteux. [/quote]
Oui, je sais bien que c'est couteux, chaque action, chaque clic utilisateur est enregistré, donc multiplié par le nombre d'utilisateur, ca peut vite chiffrer :S

[quote]As tu envisagé une solution comme log4php ?[/quote]
Euh non, car je ne connaissais pas... je vais aller y jeter un oeil alors :)

Merci en tout cas pour tes pistes ;)

heu comment dire, des tables d'historique ?, 52 tables enplus par an, ça va chiant à utiliser.

https://www.elastic.co/fr/products/elasticsearch
y a même un truc pour php
https://www.elastic.co/guide/en/elasticsearch/client/php-api/current/index.html

en gros c'est une base nosql qui expose un api rest pour communiquer avec. du coup du json et des appel réseau pour faire la chose.
si tu n'as pas plusieurs nœuds les perfs seront (grosso modo) équivalentes à une base de données si tu en a plusieurs les perfs seront meilleurs.

ensuite tu pourras faire une ihm pour fouiller la dedans qui n'aura rien a voir avec l'appli "monitorée" (tu va même pouvoir y ajouter le monitoring d'autre appli c'est cool ;)~ )

ensuite le plus pénalisant pour toi c'est pas vraiment le stockage c'est comment tu va y fourrer les choses.
car que cela soit du nosql, du sgbdr du fichier etc chaque requête va ralentir le système. Passe n'importe qu'elle appli en debug, avec des logs conséquents tu dégrades les perfs.
C'est pour cela qu'il existe des système intermédiaire : les piles.
c'est des systèmes non bloquant tu balances ton infos dedans et dès que la pile peu elle le traite. Cela permet d'éviter de bloquer l'appli en attente d'écriture on d'un retour quelconque (la tu bennes sans même savoir si ça se passe rien c'est rapide c'est tout).

bon la du coup ça commence à monter l'infra ;)

au final ce qu'il faut bien voir c'est le besoin et que tu va en faire car logguer un max c'est bien mais couteux.

As tu envisagé une solution comme log4php ?

@+

[quote]il y a déjà la fk vers la table utilisateur ;)
quand a ajouter un serveur nosql cela peu se comprendre faut pas se limiter un seul truc ;)[/quote]

[quote]dans ton cas tu peut très imaginer pousser les actions dans un elastic search et faire des requêtes de compètes dessus pour avoir des stats de folies XD

une base nosql se comprend très très si tu veux logger les action utilisateur. [/quote]

Ok, pour la base nosql, je vais y réfléchir alors.
Tu pourrais me donner un peu plus d'explications sur la façon d'utiliser Elastic Search ?
En gros, chaque action est insérée dans la base nosql, et tu te sers d'Elastic Search pour faire les requêtes ?

[quote]si tu part sur du sql faudra quand même penser à purger la table parce que quoi qu'il arrive au bout d'un moment le nombre d'enregistrement pénalisera la chose (si en plus ils servent à rien ... :) )[/quote]

Ah ca, c'est un problème que j'avais soulevé, vu le nombre d'actions ca va vite devenir imbuvable. Je pensais faire des tables générées à la volée, mensuelles ou annuelles, selon le volume des données.

il y a déjà la fk vers la table utilisateur ;)
quand a ajouter un serveur nosql cela peu se comprendre faut pas se limiter un seul truc ;)

dans ton cas tu peut très imaginer pousser les actions dans un elastic search et faire des requêtes de compètes dessus pour avoir des stats de folies XD

une base nosql se comprend très très si tu veux logger les action utilisateur.

si tu part sur du sql faudra quand même penser à purger la table parce que quoi qu'il arrive au bout d'un moment le nombre d'enregistrement pénalisera la chose (si en plus ils servent à rien ... :) )

@+

Ok, merci de ta réponse moogli.
Le côté maintenabilité est aussi un argument, c'est sûr.

Après, dans mon cas, il y a déjà un SGBDR d'utilisé sur l'appli, donc utiliser nosql juste pour ce cas précis d'utilisation n'est pas trop envisageable...

Pour le côté intégrité des données, par rapport à ma demande (stocker des actions utilisateurs sur un site), ce n'est pas primordial, pas de transactions ou de contraintes particulières. Mais c'est vrai que ça peut avoir son importance selon le cas.

Merci en tout cas ;)

salut,

le contre argument n'est pas performance mais intégrité de modèle référentiel.
une table c'est sur sur tu sais où se trouve les données mais maintenir l'intégrité référentielle la dessus doit être un cochemar, je ne parle pas des forme normale dont la 1ère ne sera certainement pas respectée (atomicité).

Bref un calvaire à utiliser et à maintenir c'est pas une bonne idée.
la normalisation des bases de données c'est quelque chose qui date des années 70, c'est éprouvée.
tu veux de la perf et du schema less => nosql.

il faut adapter au cas d'usage mais un cluster (et pas un instance ça sert à rien) nosql est très ractif et performant, mais c'est pas fait pour gérer un blog ;)


@+

Bonjour @rthur,

Désolé, je n'avais pas vu ta réponse... les champs sont plus ou moins variés, essentiellement INTEGER, CHAR, pas de textes longs par contre, DATETIME.

Habituellement, je fais plutôt des tables avec le moins de colonnes possibles, et je gère les champs supplémentaires avec des tables annexes, mais là j'ai une demande particulière me demandant une seule table avec l'ensemble des champs à l'intérieur...
j'avais un doute sur les performances, et je cherchais un contre-argument à cette méthode ;)

Sans savoir ce que tu mets dans tes enregistrements et les requêtes que tu vas faire dessus, c'est impossible à dire.

A priori, quand on voit comment sont construits les principaux CMS pour gérer des millions d'enregistrements, je dirai qu'il est préférable d'avoir le moins de colonnes possibles

Bonjour à tous,

Ma question est relativement simple : est-il préférable d'avoir une table SQL avec peu d'enregistrements et de nombreuses colonnes, ou bien au contraire une table avec peu de colonnes mais de nombreux enregistrements ?

Je schématise un peu, mais ce qu'il m'intéresse de savoir, ce sont les performances lorsqu'on commence à avoir plusieurs centaines de milliers, voire millions d'enregistrements ;)

Par exemple 10 000 enregistrements de 100 colonnes, par rapport à 100 000 enregistrements de 10 colonnes : quelle serait la table la plus facile à traiter ?

(En partant du principe qu'il y a des index sur les colonnes appropriées).

Merci beaucoup :)