使用BLOB VS OS文件系统的MySQL二进制存储:大文件,大批量,大问题

Question

我正在运行的版本(基本上是最新的):
PHP:5.3.1
MySQL:5.1.41
Apache:2.2.14
OS:CentOS(最新)

情况就是这样.

我有数千个非常重要的文件,从客户合同到语音签名(合同的客户授权记录),文件类型包括但不限于jpg,gif,png,tiff,doc,docx,xl​​s,wav,mp3 ,pdf等

所有这些文档目前都存储在多个服务器上,包括Windows 32位,CentOS和Mac等.有些文件也存储在员工台式计算机和笔记本电脑上,有些文件仍然是存储在数百个盒子和文件柜中的硬拷贝.

现在因为客户或律师可以随时要求合同证明,我公司必须能够有效地搜索和找到正确的文件,因此所有这些文件都必须数字化(如果还没有)并且相关进入某种搜索和访问的顺序.

作为程序员,我创建了一个完整的客户关系管理工具,供整个公司使用.这包括客户资料管理,订单和工作跟踪工具,工作/销售创建和管理模块等,以及目前客户资料级别(驾驶执照,信用授权等)或工作中所需的任何文件/销售级别(合同,语音签名等)可以上传到服务器并位于父/子层次结构中,就像Windows资源管理器或任何其他典型的文件管理模型一样.

结构如下:

drivers_license
| - DL_123.jpg
voice_signatures
| - VS_123.wav
| - VS_4567.wav
合同

因此,文件使用PHP和Apache进行上传,并存储在操作系统的文件系统中.在上载时,关于文件的某些信息存储在MySQL数据库中.存储的一些信息是:

表:FileUploads
FileID
CustomerID(文件所属的客户ID,它们都有此.)
JobID/SaleID(相关作业/销售的ID,如果有)
.FileSize
FileType
UploadedDateTime
UploadedBy
FilePath(文件的目录路径是存储在.)
FileName(上传文件的当前文件名,CustomerID和JobID/SaleID的组合,如果适用.)
FileDescription
OriginalFileName(上载时源文件的原始名称,包括扩展名.)

如您所见,文件通过文件名链接到数据库.当我想提供客户的文件下载给用户时,我所要做的就是"SELECT*FROM FileUploads WHERE CustomerID = 123 OR JobID = 2345;" 这将输出我需要的所有文件详细信息,并且使用FilePath和FileName,我可以提供下载链接.

http ... server/FilePath/FileName

这种方法存在许多问题:

1. 在"数据库无意识"环境中存储文件意味着不保留数据完整性.如果删除了记录,则也可能不会删除该文件,反之亦然.
2. 文件遍布整个地方,不同的服务器,计算机等.
3. 文件名是唯一匹配二进制文件到数据库和客户配置文件和客户记录的东西.

有很多原因,其中一些在这里描述:http://www.dreamwerx.net/site/article01.此外,这里也有一篇有趣的文章:sietch.net/ViewNewsItem.aspx?NewsItemID=124.

因此,经过大量研究后,我几乎已经决定将所有这些文件存储在数据库中,如BLOB或LONGBLOB,但在我这样做之前还有很多注意事项.

我知道将它们存储在数据库中是一个可行的选择,但是有许多方法可以存储它们.我也知道存放它们是一回事; 以可管理的方式关联和访问它们完全是另一回事.

此链接提供的文章:dreamwerx.net/site/article01描述了一种将上传的二进制文件拆分为64kb块并使用FileID存储每个块,然后使用标头将实际二进制文件流式传输到客户端的方法.这是一个非常酷的主意,因为它减轻了对服务器内存的预感; 而不是将整个100mb文件加载到RAM然后将其发送到客户端,它一次只做64kb.我已经尝试了这个(并更新了他的脚本),这在一个非常小的测试框架中是完全成功的.

因此,如果您同意这种方法是一个可行的,稳定的和强大的长期选项来存储适度大的文件(1kb到几百megs),以及大量的这些文件,请告诉我您有哪些其他注意事项或想法.

此外,我正在考虑获取当前的"文件管理"PHP脚本,该脚本提供了一个界面,用于管理存储在文件系统中的文件,并将其转换为管理存储在数据库中的文件.如果已经有任何软件可以做到这一点,请告诉我.

我想我可以提出很多问题,并且所有信息都在那里^^所以请讨论这方面的所有方面,我们可以来回传递想法并相互教授.

干杯,

Quantico773

Answer 1

我在一个大型软件系统上工作,该系统已经完成了存储附件和其他内容的两种机制.系统的第一次迭代将所有数据存储在DB中的BLOB中.我当时诅咒它.作为一名程序员,我可以编写辅助脚本来立即对数据进行操作并随时更改它.

提前大约10年,我仍然管理相同的软件,但架构已经改变,它是用文件系统指针编写的.我现在诅咒它并希望它回到数据库中.我有几年的额外好处,并且已经在更多更大的情况下以更大的容量使用这个应用程序,我觉得我的观点现在受到更好的教育.应用程序的升级或系统迁移需要大量脚本和数百万个文件的复制.有一次,我们更改了操作系统,所有文件指针都有错误的目录分隔符,或者服务器名称在文件所在位置发生变化,我们不得不在周末编写和安排简单的SQL更新语句与DBA进行修复.另一个是文件系统和数据库记录不同步,为什么不确定,但经过数千天的操作,有时非事务性系统(文件系统和数据库不共享事务上下文)只是变得不同步.有时文件会神秘地丢失.

当所有这些都在数据库中时,迁移或环境升级是转储和导入数据库的问题.可以正确审核行更改,同步和日志中的所有内容都可以在必要时重播到时间点.当然数据库变大了,但它是2011年,这对于数据库来说根本不是一个挑战.

对于什么是值得我们在传输一些数据时遇到大数据缓冲区的类似问题,但是A)我们可以使用JDBC和B中的Input | OutputStreams在字节缓冲区中抽取数据当使用其他工具时,我们编写了一个存储过程将BLOB块化为临时表并迭代地从临时表中提供块.效果很好.

我不在乎没有把这些东西放在数据库中的技术原因,但是在一个整合的位置管理起来要容易得多,我可以将数据库的硬件或网格加倍和三倍,这是顾问和客户浪费的时间在短时间内管理不同的文件.

更新:轻松评论评论者,他们只是就此事发表意见.