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

Question

问题:

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

背景:

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

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

数据库服务器是双四核 Windows 2003 机器，带有托管数据库文件的 SAN 驱动器。当前镜像库大小约为 650GB。我没有做任何测试来查看转换后的数据库有多大。我并不是真的在询问数据库设计——我正在与我们的 DBA 一起研究这方面的问题。如果情况有所改变，我会回来的:-)

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

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

大多数 (90%+) 文档/图像都非常小，< 100K，可能 < 50K，所以我相信将图像存储在数据库文件中比使用 SQL 2008 和使用文件流。

Answer 1

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

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