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

Question

问题：

我应该编写我的应用程序来直接访问数据库图像存储库还是编写一个中间件来处理文档请求。

背景：

我有一个自定义文档图像和工作流应用程序，目前存储大约 1500 万个文档/文档图像（90%+ 单页，4 组 tiff，其余 PDF、Word 和 Excel 文档）。图像存储库是一个商业的第 3 方应用程序，它非常昂贵并且坦率地说开销太大。我只需要一个系统来存储和检索文档图像。

我正在考虑将映像直接移动到 SQL Server 2005 数据库中。索引信息非常有限 - 基本上是 2 个索引字段。这是一个人寿保险单管理系统，因此我使用保单编号和系统范围的唯一 ID 编号对图像进行索引。还有其他索引值，但它们与图像数据分开存储和维护。这些索引值使我能够查找单个图像检索的唯一 id 值。

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

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

我主要关心的是可扩展性和性能 - 非常重视性能。我有大约 100 个用户，未来几年的使用增长可能会很慢。 大多数用户主要是阅读用户——他们不经常向系统添加图像。我们有一个部门负责扫描和以其他方式将图像添加到存储库。我们还有一些其他应用程序接收文档（通过 ftp），它们会在收到文档时自动将它们插入存储库，或者将完整的索引信息或作为用户查看和索引的“批次”。

大多数 (90%+) 的文档/图像非常小，

Answer 1

通常情况下，可扩展性和性能最终是相互结合的，因为从现在起六个月后，管理层会回来说“应用程序 X 中的函数 Y 运行速度慢得令人无法接受，我们如何加快速度？”答案通常是升级后端解决方案。在升级后端时，横向扩展几乎总是比硬件纵向扩展更便宜。

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

Answer 2

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

一旦您对自己的界面感到满意，那么应用程序（大部分）就与实现隔离，无论是直接与数据库还是其他组件通信。

提前考虑一下您的界面设计，但做的非常愚蠢，“它很简单，在这里可以工作，现在可以工作”实现提供了一个很好的平衡，既可以面向未来，又不必过度设计系统。

很容易争辩说，此时您甚至不需要接口，而只需实例化一个简单的类。但是，如果您的合同定义明确（即接口或类签名），这就是保护您免受更改（例如重做后端实现）的原因。如果您觉得有必要，您可以随时将类替换为接口。

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

这是尽职调查和负责任的设计策略，恕我直言。

Answer 3

我同意 gabriel1836 的观点。但是，另一个好处是您可以暂时运行一个混合系统一段时间，因为您不会在一夜之间将 1400 万个文档从您的专有系统转换为您自己开发的系统。

另外，我强烈建议您将文档存储在数据库之外。将它们存储在文件系统上（本地、SAN、NAS 都无所谓），并将指向文档的指针存储在数据库中。

我很想知道您现在使用的是什么文档管理系统。

此外，不要低估替换专有系统提供的捕获（扫描和导入）所付出的努力。