Bonjour,

Je n'arrive pas à trouver de réponse claire à une question qui se pose à moi:

J'ai une base de données qui grossit de 1000 lignes par minute (vrai chiffres, aucun moyen de réduire ce nombre), quelle est la taille critique pour une table MySQL? Quelles optimisations pour augmenter cette taille critique? Pour réduire le temps de lecture?

LA QUESTION LA PLUS IMPORTANTE:

Comment faire pour garder en mémoire toutes les lignes jamais crées? créer une nouvelle table? Y a t-il des solutions plus élégantes?

Merci d'avance je suis bloqué, je ne peux pas avancer si je ne règle pas cette question.

Bonjour,

1000 lignes à la minutes cela fait plus de 52 millions de lignes à l'année ... c'est en effet énorme !

Mais il va être difficile de te répondre avec si peu d'information ...

Quel est la structure de la table en question ? colonnes, types, index, contraintes ?

Quelles sont les requêtes exécutées en lecture ?

Pour chacune, quel est le niveau de sollicitation ? Plusieurs fois par minutes ? quelques fois par heure ? Une fois par mois ?

Il va de soit qu'avec ce volume, MySQL n'est peut-être pas l'outil le plus adapté, il faudrait envisager PostGreSQL, plus robuste, voir même NoSQL si la complexité des données et l'atomicité ne sont pas importantes ...

-
Edité par Benzouye 16 novembre 2017 à 16:11:05

Benzouye a écrit:

 voir même NoSQL si la complexité des données et l'atomicité n'est pas importante ...

Je croit que tu es la première personne que je vois à donner une raison valable d'utilisé NoSQL 

Si tes champs sont daté et que tu ne fait pas de lecture sur la totalité des données en permanences les table de partitionnement peuvent être une solution, par contre il faut être sur que aucune de tes requêtes n'utilise deux partitions différentes au même moment, sinon tu va plus pourrir les perf que autre chose.

Peut être que le problème est en amont ? C'est quoi ce taux de 1000 lignes à la seconde ?

Même en exploitation en mainframe sur des machines unix ou vax/Vms en 25 ans de carrière j'ai jamais vu cela. (le max que j'ai connu est en gestion de yield forecast sur histo de 5ans : ~ 20millions de lignes)

Il n'y aurais pas plutôt des updates qui passeraient à l'as dans ton système et qui se transformeraient en insert ?

-
Edité par Mon nom est God ; phil God 16 novembre 2017 à 16:22:21

Mon nom est God ; phil God a écrit:

Peut être que le problème est en amont ? C'est quoi ce taux de 1000 lignes à la seconde ?

Même en exploitation en mainframe sur des machines unix ou vax/Vms en 25 ans de carrière j'ai jamais vu cela. (le max que j'ai connu est en gestion de yield forecast sur histo de 5ans : ~ 20millions de lignes)

Il n'y aurais pas plutôt des updates qui passeraient à l'as dans ton système et qui se transformeraient en insert ?

-
Edité par Mon nom est God ; phil God 16 novembre 2017 à 16:22:21

C'est un chiffre qu'on atteint désormais très facilement dans des domaines de monitoring, comme avec l'IoT. A ce jour dans notre système en production, la plus grosse table contient 1 450 Millions de lignes en 8 ans d'exploitation (oui, plus d'un milliard ! ), sur PostgreSQL.

Ca fait ~200 lignes par heure... Nous sommes très loin de 1000 lignes par minutes, mais nous ne vendons pas des milliers d'appareils par ans non plus...

Toutefois, dans la pratique il y a peu d'intérêt de garder en historique des données vieilles de plusieurs années. Une solution serait de ne conserver que des moyennes / jour au delà de la première année, puis moyenne / semaine au delà de 3 ans, etc...

Mais effectivement, au vu du type de données sauvegardées, nous allons passé à une solution noSQL (en particulier des base de données de types timeseries) pour remplacer notre table spécifique.

Toutefois, dans la pratique il y a peu d'intérêt de garder en historique des données vieilles de plusieurs années

Si dans le cas d'expérience pour de l'IA afin de modéliser mathématiquement un univers pour déterminer les tendances futures comme dans le yield forecast en matière marketing/merchandising.

Et encore, ca va dépendre du modèle d'IA à faire. Pour le marketing, on agira souvent au niveau d'une saison, qui correspond à une année.

Dans ce contexte, conserver deux ou trois années à des fin de comparaison à un sens. Mais conserver sur plus de dix ans non par exemple. En tout cas pas avec autant de précision. Sur dix ans, on peut vouloir mettre en évidences des tendances globales. Mais pas besoin de toutes les valeurs. Des moyennes au mois seraient suffisantes.

-
Edité par Mon nom est God ; phil God 21 novembre 2017 à 8:17:40