Partitionnement vs base de données supplémentaire

Question

Où je travaille, nous avons un dilemme. Nous utilisons une base de données (MariaDB 10) qui a 1 table qui devient très grande (107.4GiB comme je l'écris, donc 1.181 millions de lignes ..). Cela affecte bien sûr les performances du système. Moi et un collègue avons eu une discussion, il a suggéré d'utiliser des partitions sur cette table. Cela augmentera probablement les performances, mais ne réduit pas la taille de la base de données. Dans le passé, cependant, j'ai travaillé sur l'écriture d'un cronjob qui déplace les données plus anciennes que 2 ans de cette table vers une copie exacte de la base de données à un autre endroit. Je pense que c'est le moyen le plus efficace. Je m'attends à ce que cela n'augmente pas seulement les performances (sauf pendant les périodes où le cronjob est en cours d'exécution) mais je sais que cela réduira également la taille de la table. Nous ne prévoyons pas que nos clients sont intéressés par ces anciennes données de toute façon.

La question est: Que choisiriez-vous? Je préfère mon option, car les anciennes données ne sont pas utilisées et la base de données principale est beaucoup plus propre, mon collègue préfère sa solution car cela signifie moins de charge à tout moment et les clients peuvent toujours accéder aux anciennes données.

J'ai lu certains des pro pour utiliser le partitionnement mais n'ont pas trouvé une comparaison encore entre le partitionnement et le déplacement d'anciennes données vers une autre base de données/placer

Le tableau en question utilise plusieurs requêtes de, Ceci est le plus important insert:

INSERT INTO ".$defaultDataTable." (
          sensor_data_type_id, 
          sequence_number, 
          value, 
          flag, 
          datetime 
         ) VALUES (
          '".Database::esc($sdtid)."', 
          '".Database::esc($valueSequence)."', 
          '".Database::esc($value)."', 
          '".Database::esc($valueSensorDataFlagsExtended)."', 
          '".Database::esc($valueDateTime)."' 
         ); 

Les données sont sélectionnées dans plusieurs pages de l'application, mais 1 exemple est le suivant.

  SELECT 
       ws_sensor_data_type.sensor_data_type_id as sensor_data_type_id, 
       ws_sensor_data_type.name as sensor_data_type_name, 
       ws_sensor_data_type.equation_id as equation_id, 
       ws_sensor.name as sensor_name, 
       ws_equation.description as data_type_name, 
       ws_basestation.network_id as network_id, 
       ws_basestation.name as basestation_name, 
       ws_basestation.worldwide_id as worldwide_id, 
       ws_client.name as client_name, 
       ws_sensor.device_type_id as device_type, 
       ws_sensor.device_id as device_id 
      FROM 
       ws_sensor_data_type, 
       ws_sensor, 
       ws_basestation, 
       ws_client_basestation, 
       ws_client, 
       ws_equation 
      WHERE ws_sensor.sensor_id = ws_sensor_data_type.sensor_id 
      AND ws_sensor.basestation_id = ws_basestation.basestation_id 
      AND ws_basestation.basestation_id = ws_client_basestation.basestation_id 
      AND ws_client_basestation.client_id = ws_client.client_id 
      AND ws_sensor_data_type.equation_id = ws_equation.equation_id 
      AND ws_sensor_data_type.sensor_data_type_id = '".Database::esc($sdtid)."' 
     "); 

Dans cet exemple, les données, ainsi que d'autres informations est sélectionné pour créer un fichier d'exportation .csv.

L'instruction create table suivra alors que je suis en train de créer une copie de la base de développement pour tester le partitionnement. Nous n'utilisons pas d'UUID, cela ne devrait donc pas poser de problème.

Answer 1

Cela dépend.

Le partitionnement n'améliore pas les performances de manière inhérente. Seul un nombre très limité de cas d'utilisation montre une amélioration des performances. More details.

Si vous ne récupérez que les lignes «récentes» de la table et que vous avez une indexation adéquate, alors «ni» est la réponse - votre million de lignes pourrait atteindre le milliard sans dégradation des performances.

Si vous utilisez des UUID, vous êtes condamné. Les performances diminuent terriblement une fois que les données sont trop volumineuses pour être mises en cache.

Vous avez effectué un "mouvement de main". Moi aussi. Si vous voulez continuer cette discussion, veuillez fournir plus de détails. CREATE TABLE, exemples de requêtes, mécanisme de partition proposé, mécanisme proposé pour accéder aux «anciennes» données, etc.