Mysql
 sql >> Base de données >  >> RDS >> Mysql

MySQL :Diviser une grande table en partitions ou en tables séparées ?

Eh bien, si vous espérez une nouvelle réponse, cela signifie que vous avez probablement lu mes réponses, et je sonne comme un disque rayé. Voir Blog sur le partitionnement pour les quelques cas d'utilisation où le partitionnement peut améliorer les performances. Le vôtre ne le fait pas ressemble à l'un des 4 cas.

Réduire device_id . INT est de 4 octets ; avez-vous vraiment des millions d'appareils ? TINYINT UNSIGNED est de 1 octet et une plage de 0..255. SMALLINT UNSIGNED est de 2 octets et une plage de 0..64K. Cela réduira un peu le tableau.

Si votre vrai question est de savoir comment gérer autant de données, alors "sortons des sentiers battus". Continuez à lire.

Représentation graphique... Quelles plages de dates représentez-vous ?

  • La "dernière" heure/jour/semaine/mois/année ?
  • Une heure/jour/semaine/mois/année arbitraire ?
  • Une plage arbitraire, non liée aux limites jour/semaine/mois/année ?

Que représentez-vous ?

  • Valeur moyenne sur une journée ?
  • Max/min sur une journée ?
  • Des chandeliers (etc.) pour le jour ou la semaine ou autre ?

Quel que soit le cas, vous devez créer (et maintenir progressivement) un tableau récapitulatif avec des données. Une ligne contiendrait des informations récapitulatives pour une heure. Je suggérerais

CREATE TABLE Summary (
    device_id SMALLINT UNSIGNED NOT NULL,
    sensor_id TINYINT UNSIGNED NOT NULL,
    hr TIMESTAMP NOT NULL,
    avg_val FLOAT NOT NULL,
    min_val FLOAT NOT NULL,
    max_val FLOAT NOT NULL
    PRIMARY KEY (device_id, sensor_id, hr)
) ENGINE=InnoDB;

Le seul tableau récapitulatif peut être de 9 Go (pour la quantité actuelle de données).

SELECT hr,
       avg_val,
       min_val,
       max_val
    FROM Summary
    WHERE device_id = ?
      AND sensor_id = ?
      AND hr >= ?
      AND hr  < ? + INTERVAL 20 DAY;

Vous donnerait les valeurs hi/lo/avg pendant 480 heures ; suffisant pour représenter graphiquement ? Récupérer 480 lignes dans le tableau récapitulatif est beaucoup plus rapide que saisir 60 x 480 lignes dans le tableau de données brutes.

Obtenir des données similaires pendant un an étoufferait probablement un package graphique, donc il peut vaut la peine de construire un résumé du résumé - avec une résolution d'un jour. Ce serait environ 0,4 Go.

Il existe différentes manières de créer le(s) tableau(x) récapitulatif(s) ; nous pouvons en discuter après avoir réfléchi à sa beauté et lu le Blog des tableaux récapitulatifs . Il se peut que la collecte d'une heure de données, puis l'augmentation du tableau récapitulatif, soit le meilleur moyen. Ce serait un peu comme la bascule discutée mon blog sur la table Staging .

Et, si vous aviez les résumés horaires, avez-vous vraiment besoin des données minute par minute ? Pensez à le jeter. Ou peut-être des données après, disons, un mois. Cela conduit à utiliser le partitionnement, mais uniquement pour son avantage dans la suppression des anciennes données comme discuté dans "Cas 1" de Blog de partitionnement . Autrement dit, vous auriez des partitions quotidiennes, en utilisant DROP et REORGANIZE tous les soirs pour décaler l'heure de la table "Fait". Cela conduirait à réduire votre empreinte de 145 Go, mais sans perdre beaucoup de données. Nouvelle empreinte :environ 12 Go (résumé horaire + détails minute par minute des 30 derniers jours)

PS :Le blog du tableau récapitulatif montre comment obtenir l'écart type.