Discussion :

[garkhan]

Bonjour à tous,

Tout d'abord, je vous expose mon problème :

Il s'agit d'une table qui contiendra environ 5'000'000 d'enregistrement par année, ces enregistrements seront conservés au minimum 10 ans (voir plus, ce n'est pas encore défini). On parle d'événements de machine de production. Je vais générer un rapport + un dashbord permettant de visualiser différentes informations (moyenne du nombre d’événement par 10min sur un mois par exemple, graphiques, ...) relativement complexe et on veut également visualiser les enregistrements eux-même. Les données visualisés seront en grand majorité sur les 2 derniers mois, la visualisation du reste des données doit toujours être possible mais la rapidité d'accès un moins importante.

Je travaille sur une base de données MariaDB v10.1.12.

L'idée était de faire une partition sur les 3 derniers mois. Je me rends compte maintenant que ce n'est pas si facile. Je n'ai pas trouvé de solutin pour faire cette partition, en effet, il est impossible de faire une partition basé sur un now() ou autre current_date(), etc même indirectement via colonne calculée ou autre.

Avez-vous des idées à me proposer? Peut-être d'autre solution que cette partition.

Merci d'avance.

[Artemus24]

Salut garkhan.

A lire :
--> http://krierjon.developpez.com/mysql/partitionnement/

L'idée était de faire une partition sur les 3 derniers mois.

Pourquoi faire une partition sur trois mois ? Le plus simple est de faire une partition sur un seul mois.
Vous avez comme critère le mois issu d'une quelconque date dans votre table.

il est impossible de faire une partition basé sur un now() ou autre current_date(), etc même indirectement via colonne calculée ou autre.

Et pourquoi donc ?

Normalement, votre requête sera basée sur un critère.
Pourquoi ne pas utiliser ce même critère pour créer vos partitions ?

Avez-vous des idées à me proposer?

Il faudrait que l'on sache exactement ce que vous voulez faire avec vos partitions. Essayez de d'écrire vos contraintes !
Une partition, c'est juste une façon de découper une table en plusieurs fichiers physiques sur le disque dur.

Peut-être d'autre solution que cette partition.

Vu la volumétrie, le mieux est de faire des partitions.
Et rien ne vous empêche de mettre chaque partition sur des disques différents.

@+

[Michel Rotta]

Il faut bien faire attention aux partitions, elles peuvent être plus pénalisantes qu'être un avantage. De plus il faut éviter les mouvements entre partitions, un enregistrement ne devrait pas avoir à changer de partition, c'est une opération lourde. Autre contrainte sur les partitions, le critère de la partition doit se retrouver dans chaque requêtes faîtes sur la table, en effet, une requêtes prenant en compte plusieurs partitions est plutôt lourde, généralement plus lourde que cette même requête portant sur une table identique non partitionnée et bien indexé.

Et pour finir, 5 millions d'enregistrement n'est pas nécessairement une grosse table.

La question est plus comment calculer rapidement les résultats à afficher. Il pourrait être intéressant d'envisager un fonctionnement à la BI, soit une deuxième base de donnée qui ferait l'effet d'un datawarehouse, avec des tables et des données spécifiquement calculées pour répondre à la demande de rapport. Il reste alors à mettre en place un mini ETL entre les deux bases (qui peuvent être sur des machines différentes pour des questions de performances) et la fréquence de rafraichissement.

Si l'affichage doit être en temps réel il est toujours possible de créer les tables pré-calculée en temps réel sur le même serveur et de les mettre à jour avec soit avec des triggers, soit à l'aide d'events. Il conviendra, alors, de rajouter une tâche de nettoyage de ces tables intermédiaires qui passerait régulièrement.