MySQL BLOB图像数据逐渐丢失?

Nik*_*aul 5 c# mysql blob image image-processing

在mysql MyISAM类型表中有一个列Image类型mediumblob并存储捕获的图像.我得到了一些有趣且有问题的图像.一些图像是gradually losing数据.

Field          type  
--------------------------
image         mediumblob
Run Code Online (Sandbox Code Playgroud)

my.ini 最大允许数据包大小设置 max_allowed_packet = 8M

此搜索 图像2 图像3

这就是问题

C#应用程序每次从服务器获取数据时,这些图像逐渐丢失数据并随机大小.我10-12100000+图像数据中得到了这样的坏图像.

这种行为可能是什么原因?任何人都有任何想法/解决方案如何解决/避免这个问题.

更新1:
从PictureBox读取字节

MemoryStream ms = new MemoryStream();
byte[] ret = null;

try
{
     picturebox.Image.Save(ms, System.Drawing.Imaging.ImageFormat.Jpeg);
     byte[] Data = new byte[ms.Length];
     ms.Read(Data, 0, (int)ms.Length);
     ret = byteData;
     ms.Close();
 }         
Run Code Online (Sandbox Code Playgroud)

将bytes数组保存为数据库作为中等blob数据.从数据库中检索数据时,我正在转换读取器数据

byte[] Data = (byte[])reader["Image"];
Run Code Online (Sandbox Code Playgroud)

c2h*_*5oh 5

首先,正如Sarke所提到的,在DB中存储文件内容并不是最好的想法(文件元数据是一个完全不同的故事.

为什么?

  1. 性能:在大多数情况下,OS文件缓存将优于DBMS中内置的任何内容.
  2. 灾难恢复:失败时丢失所有/大多数文件的几率远高于文件系统,恢复要困难得多
  3. 扩展:如果您增加单个服务器的容量,添加应用程序级别分片是微不足道的,并且没有性能损失.多服务器数据库设置更"痛苦"
  4. 提供多种解决方案/易于迁移:有大量用于大型文件集存储的硬件和软件解决方案,并且在它们之间进行迁移比在DBMS之间迁移要简单得多

我存储了近200万个存储在简单文件夹结构中的图像:/xx/yy/filename,其中filename =文件的md5(+可选的数字应该发生哈希冲突),xx = md5的前2个字符,yy = md5的第3个和第4个字符.它工作得很好,我不应该长时间得到任何FS相关的减速(至少2个数量级).

回到你的问题有3个选项

  1. 文件永远不会正确保存到数据库中.在上传照片或图片太大的应用中可能会出现问题.您max_allowed_packet将图像大小限制为~8 MB,mediub_blob最多可存储16 MB.为了统治这个,增加到max_allowed_packet32 MB并进行测试.您需要确保任何时候没有图像超过此尺寸,并确保应用程序在上传照片时能够正常工作.如果您可以找到上传并显示正常的图像(来自DB!),之后它没有,那么这不是原因.
  2. 更新过程中文件损坏 - 如果有任何方式更新照片,那么即使原始文件很好,更新的文件也可能没有 - 例如,它可能会超过第1点的大小限制.
  3. (最不可能的一个)如果文件存储和更新而不损坏它,那么它在存储时会被损坏 - >没有报告MySQL错误(这不会被忽视)我会查看服务器硬件.


Aka*_*ava 4

罪魁祸首是MyISAM存储类型。

我们使用InnoDB存储存储100万张图像并进行压力测试,得到了正确的结果。要么文件被正确检索,要么根本没有检索到(小于 0.01%),因为 InnoDB 符合 Acid 标准。

当我们转向 MyISAM 时,失败率增加到 20%,并且数据丢失,与您的情况相同。原因是,MyISAM 使用表锁,因此在写入时整个表都会被锁定,如果超时,它会覆盖某些内容,从而导致数据丢失。

我们现在已经将一切转移到 MS SQL,因为 InnoDB 性能良好,但它仍然从不重用已删除的文件空间,因此 InnoDB 不断增长。MS SQL Express 的限制为 10GB,因此我们创建了 4-8GB 的​​页面并在那里存储 blob。我们有自己的自定义复制,可以使用相同的配置在网络上的三台服务器上复制文件。

由于多种原因,将文件存储在磁盘上是不好的,每个人都一直说文件系统是为高性能而设计的,可以存储数百万个文件,但事实并非如此,当文件超过 10 万个时,驱动器无法更快地执行。它们在处理 1 个大文件和 1000 个小文件时表现良好。目前我们正在存储 1000 万个文件,并将其存储在 db 中更有意义,因为 db 对查询进行了优化并进行了良好的缓存。您可以在http://akashkava.com/blog/127/huge-file-storage-in-database-instead-of-file-system/阅读更多信息

这就是 MongoDb、Hadoop、Azure Blob Store、Haystack 和 Amazon S3 被发明的确切原因。