Est-ce une chose courante pour les plus grandes applications et les bases de données pour Gzip Text Data avant de l'insérer dans la base de données?
Je vais deviner que toute recherche de texte intégral sur le champ de texte actuel ne fonctionnera pas avant de la découvrir à nouveau?
3 Réponses :
mauvaise idée. Traitement supplémentaire Pour enregistrer un espace lorsque l'espace disque est inférieur à 1 Go de 1 Go ne compensera pas le temps de programmation supplémentaire pour le faire (pas seulement au départ, souvenez-vous de la maintenance).
Cela rendra probablement une accès à la base de données plus lente car les données doivent être décompressées / comprimées. Les index ne fonctionnent pas correctement sur les données compressées car vous auriez besoin d'une analyse de table, décompressez les données, puis comparez. Et la recherche de texte complète est également disponible.
Si vous devez le faire, veuillez n'utiliser pas gzip. Utilisez l'intégré compresse fonction. < / p>
Certains cas d'utilisation valides pour la compression de votre couche d'application. Chaque fois que vous stockez de grandes quantités de données texte mais que vous n'avez pas besoin de rechercher contre elle est un excellent candidat, tel que la sortie du journal d'archivage. Gzipping Data avant qu'il ne frappe que la base de données réduit un journal de 1 Mo jusqu'à 30k. Bien que l'espace disque immédiat soit bon marché, vous devez également envisager des limitations IO lors de l'exécution de MySQLDUMPS, ou simplement lorsque vous traversez le réseau lui-même de votre serveur d'applications sur le serveur DB. Si vous avez déjà exécuté un verrouillage mysqldump -Master-Data Lorsque vous configurez un esclave pour la production, vous voudrez réduire la taille de la DB.
Je n'ai pas vu cela fait beaucoup, car il empêche fondamentalement l'un de faire toute manipulation sur les données sur le côté MySQL:
comme , aucun = , aucune autre manipulation ...
Néanmoins, si vous utilisez votre base de données uniquement pour stocker ces données et ne pas le manipuler, cela pourrait être intéressant.
Remarque: Vous voudrez peut-être effectuer quelques points de repère, pour mesurer l'impact de la performance, cela pourrait avoir, car la compression / la décompression nécessite CPU!
Après cela, la question est la suivante: allez-vous traiter de la compression sur le côté client (PHP) ou sur le côté serveur (mySQL)?
Dans le second cas, il y a un compresse () fonction, fournie par MySQL, qui pourrait vous intéresser.
Si vous utilisez le type de table Innodb dans MySQL avec l'une des versions les plus récentes, il est possible d'activer compression sur une table innodub elle-même.
Il est géré au niveau bas afin de ne pas changer vos requêtes ni quoi que ce soit. De ce que j'ai lu, la légère surcharge de compression est décalée en réduisant le disque IO et en permettant de stocker plus de données dans le pool tampon en mémoire. Vous avez cependant mentionné une recherche en texte intégral que InnoDB ne prend pas en charge, il peut donc ne pas être une option.
Il y a aussi un Archive Type de table dans MySQL mais Vous perdez une indexation de la fonctionnalité en dehors de la clé primaire que je crois.
Une autre alternative consiste à "emballer" une table myisam, mais je crois que la table ne se lit que et ne compresse pas ainsi que les autres options.
METTRE À JOUR. InnoDB prend en charge la recherche de texte intégral depuis MySQL 5.6 publiée au 5 février 2013.