代码之家 › 专栏 › 技术社区 › rjrapson

文档/图像数据库存储库设计问题

document-imaging middleware sql-server

3

rjrapson · 技术社区 · 17 年前

问题:

背景:

我有一个定制的文档图像和工作流应用程序,目前可存储约1500万个文档/文档图像(90%+单页、第4组TIFF、其余PDF、Word和Excel文档)。映像存储库是一个商业的第三方应用程序,它非常昂贵,坦率地说,开销太大。我只需要一个系统来存储和检索文档图像。

我正在考虑将映像直接移动到SQLServer2005数据库中。索引信息非常有限,基本上只有两个索引字段。这是一个人寿保险单管理系统,所以我用一个保单号和一个系统范围内的唯一id号索引图像。还有其他索引值,但它们与图像数据分开存储和维护。这些索引值使我能够为单个图像检索查找唯一的id值。

数据库服务器是一个双四核windows 2003机箱,带有承载DB文件的SAN驱动器。当前图像存储库大小约为650GB。我还没有做任何测试来查看转换后的数据库有多大。我并不是真的在问数据库设计——我是在和我们的DBA在这方面合作。如果情况发生变化,我会回来:-)

当前要替换的系统显然是一个中间件应用程序,但它是一个非常重的系统,分布在3台windows服务器上。如果我走这条路,它将是一个单服务器系统。

我主要关心的是可伸缩性和性能,这在很大程度上取决于性能。我有大约100个用户,在接下来的几年里,使用量的增长可能会很慢。大多数用户主要是阅读用户-他们不经常向系统添加图像。我们有一个部门负责扫描和向存储库添加图像。我们还有一些其他应用程序接收文档(通过ftp),它们在接收文档时自动将文档插入到存储库中,要么将完整的索引信息,要么作为用户查看和索引的“批次”。

大多数(90%+)文档/图像都非常小,<可能是10万英镑<50K,因此我相信在数据库文件中存储图像将是最有效的,而不是使用SQL 2008和filestream。

3 回复 | 直到 17 年前

1

4

Noah Goodrich 17 年前

因此,长话短说,我建议构建一个中间件应用程序,专门处理来自用户应用程序的传入请求,然后将它们路由到适当的目的地。这将从后端存储解决方案中充分提取前端用户应用程序,以便在可伸缩性确实成为问题时,只需要更新中间件应用程序。

2

Will Hartung 17 年前

这很简单。将应用程序写入接口,使用某种工厂机制提供该接口,并根据需要实现该接口。

在界面设计上想一想,但做一件非常愚蠢的事,“它很简单,在这里可以工作,现在就可以工作”的实现提供了一个很好的平衡,既能证明系统的未来性,又不必过度设计它。

很容易争辩说,此时您甚至不需要接口,而只需要实例化一个简单的类。但是,如果您的契约定义良好(即接口或类签名),那么这就是保护您不受更改(例如重做后端实现)影响的原因。如果有必要,您可以在以后使用接口替换该类。

就可伸缩性而言,测试它。然后,您不仅知道是否需要扩展,还可能知道何时需要扩展。“对于100个用户来说,效果很好,200的问题,如果我们达到150,我们可能会考虑再看后端,但现在是好的。”

3

1

Jim Blizard 17 年前

我同意加布里埃尔的观点。然而,另一个好处是,您可以在一段时间内运行一个混合系统,因为您不会在一夜之间将1400万个文档从专有系统转换为您自己开发的系统。

此外,我强烈建议您将文档存储在数据库之外。将它们存储在一个文件系统(本地、SAN、NAS都不重要)上,并将指向文档的指针存储在数据库中。

我想知道你们现在使用的是什么文件管理系统。

另外,不要低估替换由专有系统提供的捕获(扫描和导入)的工作。