php - MySQL:高效的 Blob 处理？

Question

我正在处理最多 - 我估计 - 大约 100 KB 的 blob尺寸。数据已经被压缩。

存储引擎:InnoDB on MySQL 5.1

前端:PHP(带有 Propel ORM 的 Symfony)

一些问题:

• 我在某处读到过更新 blob 不好，因为它会导致重新分配、碎片化，从而导致糟糕的结果表现。真的吗？有这方面的引用吗？

• 最初，blob 是通过附加数据 block 来构造的。每个chunk 的大小最大为 16 KB。使用a更有效吗相反，单独的 block 表，例如具有如下字段？

  parent_id、位置、 block

  然后，要获取整个 blob，可以执行以下操作:

  从 block 中选择 GROUP_CONCAT( block ORDER BY 位置)，其中parent_id = 187

  结果将在 PHP 脚本中使用。

• 除了元数据所需的大小，应该可以忽略不计。

Answer 1

如果您在表中创建和删除数据，您将获得表数据结构的碎片。

我不认为你可以通过将 blob 分割成 block 来获得任何东西 - 在数据库对数据进行碎片化之前对数据进行碎片化你不会获得任何东西:)

您可以通过重建表的结构来对其结构进行碎片整理(MySQL 中为 OPTIMIZE TABLE)。

我找不到 MySQL 如何在磁盘上存储 blob 的信息。如果它将它们与其他行数据存储在一起，那么您可以使用聚集索引(InnoDB 中的 PK，MyISAM 中的 ALTER TABLE ORDER BY)来要求表的数据文件中的数据具有特定的顺序(例如，按受欢迎程度排序以创建“热门”区域，这可能会改善缓存并减少一点查找)。

除了数据库自身结构的碎片之外，文件系统中还存在表文件的碎片问题。

即使您仅将数据插入到表本身零碎片的表中，保存表文件的文件系统迟早也会在磁盘上将其碎片化。在安全文件系统上这是不可避免的，因为它们永远不会就地更新文件数据。

如果碎片是一个问题，那么我会在尽可能低的级别上攻击它。不要在数据库中存储 blob，仅存储对磁盘上文件的一些引用。

文件系统更接近物理磁盘，因此它们可以比数据库查询更好地处理碎片，数据库查询比它上面的抽象级别少。某些文件系统会自动对小文件进行碎片整理，但会留下大文件碎片。

或者您可能只是使用硬件来解决问题 - 使用 RAID、为磁盘/数据库缓存添加大量 RAM 或使用 SSD。

当然，您已经仔细对其进行了基准测试，并且知道碎片首先是一个问题，对吗？