Question

Data_bin compression

  • 26 January 2023
  • 7 replies
  • 157 views
A
Badge +1

Bonjour,

 

Notre base de données devient vraiment volumineuse et difficile à gérer au niveau des backups (+300Go). Nous souhaitons conserver notre rétention par défaut (1 an)

Nous avons l’idée de mettre la table data_bin qui prends 99% de cette espace en COMPRESSION via mariadb

 

ALTER TABLE data_bin PAGE_COMPRESSED=1;

Est ce que Centreon supporte cette modification coté BDD, sensé être totalement transparente coté applicatif ? Nous sommes sur des SSD et les prérequis sont validés.

 

Merci 

7 replies

Fabrix
Rank
Userlevel 5
Badge +11

Hi @arampon, Please ask your problem in English. This will help all other non-french speaking users who have the same issue to benefit from the solutions that will be proposed. Thank you for your understanding : ) 

Here to help you enjoy your experience on The Watch ¯\_ (ツ) _/¯
A
Badge +1

Hello

 

Our database size is being critical (more than 300Gb) , specially the data_bin table.

Can we use, on mariadb database side, the compression option ? Is it supported by Centreon application ?

ALTER TABLE data_bin PAGE_COMPRESSED=1;

Thanks 

V
Badge +3

I’m following

S
Userlevel 1
Badge +8

Bonjour @arampon,

je déterre ton ticket car nous sommes dans le même cas (data_bin augmente rapidement). Quel est ton retour d’expérience sur le passage du data_bin en compressed ?

Cordialement 

If there's no solution to your problem, create your own.
omercier
Rank
Userlevel 4
Badge +12

Hi, 

We have not tested this feature, and do not support it officially, so do it at your own risk. I won’t recommend to do it on a production server.

 

For your information, the data_bin table is used to:

  • feed the MBI storage server on a daily basis
  • regenerate the RRD files ocasionnally (only when triggered by the user)

If your have interest in none of these use cases, you can disable the insertion into data_bin in the central broker output configuration.

I love it when a plan comes together!
B
Userlevel 2
Badge +8

Salut,

J’ai fait mes propres tests, je vous partage ici mes conclusions, avec la méthode «Page compression» qui semble être la méthode recommandée.

Les tests ont été fait sur MariaDB 10.5.23

 

Page compression

Cette compression ne fonctionne que pour les nouvelles données ingérées, car elle s’effectue lors de l’écriture des page. Les données déjà présentes, ne seront pas compressées.

Le test à été fait avec un jeux de données de la base «centreon_storage» qui faisait environ 8 Go.

La méthode à été de créer une base «centreon_storage» vide, d’activer la compression sur les tables, et d’injecter les données.

  Espace occupé Espace libre Ratio
Avant injection des données 688M 50G  
Après injection SANS la compréssion 8.1G 42G  
Après injection AVEC la compression 3.0G 47G 37%
 

Un autre test a été fait en dupliquant le flux SQL de C. Broker vers une base «centreon_storage» vide, sur laquelle la compression des tables était activée.

Les données ont été injectées pendant 24h.

Base Taille Ratio
non-compressée 883 Mo  
compressée 369 Mo 41,8%
B
Userlevel 2
Badge +8

(J’ai oublié de préciser)

 

Impact sur le serveur

Aucun impact n’a été observé sur le serveur (load, mémoire, i/o, ...), sauf sur le nombre d’opérations/s sur le log de InnoDB, qui est plus important lors des pics réguliers (tout les 1h et ¼ environ).

Les pics sont passé de ~10 à 20 ops/s. Malgré cette augmentation, nombre d’opérations/s sur le log de InnoDB reste très faible en absolu.

Reply


Terms & ConditionsCookie settings