MySQL: Blobbing efficace?

Question

Je fais face à des blobs jusqu'à - j'estime - environ 100 kilo-octets en taille . Les données sont déjà compressées.

moteur de stockage InnoDB MySQL 5.1

Frontend: PHP (Symfony Propel ORM)

Quelques questions:

• je l'ai lu quelque part que ce n'est pas bon de mettre à jour blobs , parce que il conduit à la réallocation, la fragmentation, et donc mauvaises performances . Est-ce vrai? Toute référence à ce sujet? Initialement, les blobs sont construits en ajoutant des blocs de données. Chaque bloc a une taille maximale de 16 kilo octets. Est-il plus efficace d'utiliser une table de blocs séparés à la place, par exemple avec des champs comme ci-dessous?

  parent_id, position, chunk

  Ensuite, pour obtenir l'ensemble de blob, on pourrait faire quelque chose comme:

  SELECT GROUP_CONCAT(chunk ORDER BY position) FROM chunks WHERE parent_id = 187

  Le résultat serait utilisé dans un script PHP.

• Y at-il une différence entre les types de blobs, à l'exception de la taille nécessaire pour les métadonnées, qui devrait être négligeable.

Answer 1

Si vous créez et supprimer des données dans un tableau, vous obtiendrez la fragmentation de la structure de données de table.

Je ne pense pas que vous pouvez gagner quoi que ce soit par blobs diviser en morceaux - vous ne gagnez rien par des données fragmenter avant fragments DB it :)

Vous pouvez défragmenter la structure de table en reconstruisant (OPTIMIZE TABLE dans MySQL).

Je n'ai pas pu trouver d'informations sur la façon dont MySQL stocke les blobs sur le disque. Si elle les stocke avec d'autres données de ligne, vous pouvez utiliser l'index clusterisé (PK dans InnoDB, ALTER TABLE ORDER BY dans MyISAM) pour requérir un ordre de données particulier dans le fichier de données de la table (par exemple, trié par popularité pour créer une zone "chaude" cherchant un peu).

En plus de la fragmentation de la structure de la base de données, il y a un problème de fragmentation du fichier de la table dans le système de fichiers.

Même si vous avez uniquement inséré des données dans la table sans aucune fragmentation de la table elle-même, le système de fichiers qui contient le fichier table le fragmentera tôt ou tard sur le disque. C'est inévitable sur les systèmes de fichiers sécurisés car ils ne mettent jamais à jour les données du fichier sur place.

si la fragmentation est un problème, alors je l'attaquerais au plus bas niveau possible. Ne stockez pas d'objets blob dans la base de données, ne stockez que quelques références aux fichiers sur le disque.

Les systèmes de fichiers sont plus proches du disque physique, de sorte qu'ils peuvent gérer la fragmentation bien mieux que la requête DB, avec quelques niveaux d'abstraction au-dessus. Certains systèmes de fichiers défragmenter automatiquement petits fichiers, mais laisser les fichiers volumineux fragmentés. Ou vous pouvez simplement lancer le matériel sur le problème - utiliser RAID, ajouter une tonne de RAM pour les caches disque/DB ou utiliser SSD.

Et bien sûr, vous l'avez comparé avec soin et vous savez que la fragmentation est un problème en premier lieu, n'est-ce pas?