gestion/compression de grands ensembles de données dans plusieurs tables

Question

Dans une application de notre société, nous collectons des données statistiques à partir de nos serveurs (chargement, utilisation du disque, etc.). Comme il y a une énorme quantité de données et que nous n'avons pas besoin de toutes les données à tout moment, nous avons eu une routine de "compression" qui prend les données brutes et calcule min. max et average pour un certain nombre de points de données, stockez ces nouvelles valeurs dans la même table et supprime les anciennes après quelques semaines.

Maintenant, je suis chargé de réécrire cette routine de compression et la nouvelle routine doit conserver toutes les données non compressées dont nous disposons depuis un an dans une table et les données "compressées" dans une autre table. Mes principales préoccupations sont maintenant de savoir comment gérer les données écrites en continu dans la base de données et d'utiliser ou non une "table de transactions" (mon propre terme car je ne peux pas en trouver un meilleur, je ne parle pas du commit/fonctionnalité de transaction de restauration).

A partir de maintenant nos collecteurs de données insèrent toutes les informations dans une table nommée ovak_result et les données compressées finiront dans ovak_resultcompressed. Mais y at-il des avantages ou des inconvénients spécifiques à la création d'une table appelée ovak_resultuncompressed et juste utiliser ovak_result comme un «stockage temporaire»? ovak_result serait maintenu minimal ce qui serait bon pour la routine de compression, mais je devrais mélanger toutes les données d'une table dans une autre continuellement, et il y aurait la lecture, l'écriture et la suppression constantes dans ovak_result.

Existe-t-il des mécanismes dans MySQL pour gérer ce genre de choses?

(S'il vous plaît noter: Nous parlons ici d'assez grands ensembles de données (environ 100 M lignes dans la table non compressée et environ 1-10 M lignes dans la table compressée) .En outre, je peux faire à peu près ce que je veux avec des configurations logicielles et matérielles, donc si vous avez des astuces ou des idées concernant les configurations MySQL ou la configuration matérielle, il suffit de les mettre en marche.)

Answer 1

Essayez de lire sur le ARCHIVE storage engine.

---

Pour votre clarification. D'accord, je n'ai pas compris ce que vous vouliez dire de votre description. En lisant plus attentivement, je vois que vous avez mentionné min, max et average.

donc ce que vous voulez est une vue matérialisée qui met à jour calculs globaux pour un grand ensemble de données. Certaines marques de SGBDR telles qu'Oracle ont cette fonctionnalité, mais pas MySQL.

Un produit expérimental qui tente de résoudre ce problème est appelé FlexViews (http://code.google.com/p/flexviews/). Ceci est un outil compagnon open-source pour MySQL. Vous définissez une requête en tant que vue par rapport à votre ensemble de données brutes, et FlexViews surveille en permanence les journaux binaires MySQL, et quand il voit les changements pertinents, il met à jour uniquement les lignes de la vue qui doivent être mises à jour. Il est assez efficace, mais il a quelques limitations dans les types de requêtes que vous pouvez utiliser comme vue, et il est également implémenté dans le code PHP, donc il n'est pas assez rapide pour suivre si vous avez un trafic très élevé. table de base.