背景:
我们有很久以前实施的内部文件存储系统.无论出于何种原因,选择使用数据库作为文档的存储机制.
我的问题是:
存储文档的最佳做法是什么？有哪些替代方案？优缺点都有什么？ 答案不一定是技术或平台特定的,它更像是一般的最佳实践问题.
我的想法:
数据库不适用于文档存储.文件系统或第三方文档管理系统可能会更好用.数据库中的文档存储是昂贵的.操作很慢.这些逻辑假设是什么？也许这是最好的,但在我看来,我们有更好的选择.oracle BFILE(链接到NAS或SAN上的文档)能否优于BLOB/CLOB？
细节:
文件种类繁多(pdf,word,xml)
中间层代码是用.net 2.0/c#编写的
文档通过压缩存储在BLOB中的Oracle 10g数据库中(NAS存储)
文件大小愤怒
文件数量急剧增加,并没有放缓的迹象
在峰值期间,插入物通常是每小时的hunderds
在高峰期,回归通常是每小时数千
NAS存储和SAN存储可用
更新(来自以下问题):
我的背景是发展
有关于存储在数据库中文件旁边的文件的关联元数据
MBCook.. 13
根据我的经验,我会说将它们保存在数据库中.我们已经将两个系统移动到了这个位置.
将它放在数据库中意味着:
它甚至可以从多个服务器轻松访问
它会自动备份(而不是必须有一个单独的工作来做)
您不必担心空间(因为人们不会让数据库过度填充磁盘,但可能忘记监视文档的存储位置)
您不必拥有复杂的目录方案
我们有数据库以外的文件.它成为许多文件的问题.Linux中的普通目录是一个块,通常是4K.我们有一个58MB的目录,因为它有很多文件(它只是一个平面目录,没有层次结构).它有很多间接块.删除花了一个多小时.花了几分钟来计算目录中的文件数.这太糟糕了.这是在ext3上.
使用您需要的文件系统:
独立的备份机制(来自数据库备份)
保持同步(因此,如果没有文件,数据库中不存在记录)
存储层次结构(以防止上面列出的问题,因此没有目录最终会有10,000个文件)
如果需要集群,可以从其他服务器查看它们的一些方法(可能是NFS或其他类似的)
这真的很痛苦.对于任何非常重要的文档,我建议根据我所见的文件系统.
根据我的经验,我会说将它们保存在数据库中.我们已经将两个系统移动到了这个位置.
将它放在数据库中意味着:
它甚至可以从多个服务器轻松访问
它会自动备份(而不是必须有一个单独的工作来做)
您不必担心空间(因为人们不会让数据库过度填充磁盘,但可能忘记监视文档的存储位置)
您不必拥有复杂的目录方案
我们有数据库以外的文件.它成为许多文件的问题.Linux中的普通目录是一个块,通常是4K.我们有一个58MB的目录,因为它有很多文件(它只是一个平面目录,没有层次结构).它有很多间接块.删除花了一个多小时.花了几分钟来计算目录中的文件数.这太糟糕了.这是在ext3上.
使用您需要的文件系统:
独立的备份机制(来自数据库备份)
保持同步(因此,如果没有文件,数据库中不存在记录)
存储层次结构(以防止上面列出的问题,因此没有目录最终会有10,000个文件)
如果需要集群,可以从其他服务器查看它们的一些方法(可能是NFS或其他类似的)
这真的很痛苦.对于任何非常重要的文档,我建议根据我所见的文件系统.
我更喜欢将文档存储在文件系统中,然后存储数据库中文件和关联文件元数据的链接.
事实证明,它比替代品更方便,更易于维护并且更便宜.
大多数企业级文档管理系统不会将对象文件存储在数据库中.仅仅因为你可以并不意味着你应该.如果可伸缩性和性能对您很重要并且您拥有大型文档集,则需要非常小心地将对象存储在db中.考虑以下:
在文档成像的情况下,2亿个TIFF文件可以被认为是相对较大但不是庞大的系统.较大规模的系统可以拥有超过10亿个目标文件.比方说,每个双色调TIFF 20KB,你可以有4TB的目标文件存储空间.您的数据库备份需要多长时间？你的查询需要多长时间？这些对象的访问频率是多少？如果这些对象具有较高的访问频率,您是否希望高端数据库服务器花费所有时间来提供文件？如果您有数百万个对象,那么您需要非常小心如何构建对象存储在db中的解决方案.
假设您现在的任务是将这些200M TIFF文件转换为PDF文件.准备好让您的解决方案瘫痪,因为您的数据库服务器浪费时间将每个目标文件提供给转换过程,然后重新保存结果.
举个例子,Sharepoint以在db中存储对象而闻名.Sharepoint也因可扩展性问题而闻名.
我的回答:
对于小型系统(<1M文件),可以考虑在DB中存储文件.对于大型系统(> 1M文件),在DB中存储文件是错误的.
将文件存储在数据库本身的最大问题是管理备份和其他数据库维护操作的大小和复杂性.
缓解此困难的一种策略(至少在MS SQL中)是创建单独的数据库分区,可能存储在不同的驱动器上.
然后分离数据模式,以便有关文件的元数据位于一个分区上,而实际的BLOB文件位于单独的分区中.
这些分区可以按不同的计划备份,甚至可以单独恢复.
将文档存储在数据库中的唯一限制是技术性的.
一个关系型数据库,就是要在企业的关键任务数据的持久化存储.当然,它可以执行该功能的程度因数据库,数据库和系统而异.但理想的ACID一个的特性关系数据库的意图,使其所有的商店企业数据.文件系统,修订控制器系统和其他本地存储存储系统可能具有特定的优点,但它们并非设计用于企业数据存储.
如果您存储的文档符合企业数据 - 如果它们在整个企业中持续使用 - 那么将它们保存在数据库中是合乎逻辑的.如果您在数据库中存储时遇到问题,DBA可能会找到更好的解决方案.出于性能原因,您甚至可能不得不将它们移出数据库,但出于最佳实践原因,我认为您不应将它们移出数据库.
当然,如果文档不是企业数据,如果它们仅用于一个应用程序,那么将它们移出数据库也是有意义的.
京公网安备 11010802040832号 | 京ICP备19059560号-6 