3

首先，我不是数据库专家，而是承包商。我聘请了一位（优秀的）程序员，但由于我们遇到的一些问题以及我正在阅读的所有信息，我现在对数据库设计的某个部分有一些疑问。开始吧。

我们构建了一个住宅站点，该站点使用解析器来处理所有数据并将其存储在 ms-sql 数据库中。每天提要包含大约 70.000 条记录，其中大多数还附有图片（平均 3 张）。图片大小从 30kb 到 400kb 不等。数据库有大约相同数量的记录。大约有 400 个新对象需要处理。这意味着每天都必须输入数据库中的所有记录，以查看数据是否已更改、对象是否已删除或是否为新对象并因此必须插入。图片存储在数据库中。提要在具有 32GB 内存和 SSA 磁盘的双四核机器上处理。数据库现在大小为 600GB。

目前，我们每天有大约 3000 名用户查看 6 所房子，平均每个用户查看 10 张图片。

这是我们所经历的： - 整个解析过程大约需要13个小时。- 我们在日志中收到很多超时错误 - 我们退出了一些死锁错误 - Google 抱怨超时错误，因此索引的页面不多。- 由于某些目录的加载时间超过 10 秒，谷歌将该网站评为缓慢。

我个人认为这与数据库中的图片和一些错误的查询有关。但在我开始向我的程序员抱怨之前，我想听听你对此的看法。在此先感谢您的时间。

来自我的程序员的更新：这是有关表结构的一些信息。图像有 2 个表，1 个称为 imageinfo，用于查询图像（例如获取图像 ID 和内容类型的列表）和一个包含图像 ID 和 BLOB 的图像表。imageinfo 表与图像表具有相同的 id（1:1 关系），并具有一些额外的信息，例如图像的名称、类型和哈希值。该散列在解析器过程中用于确定图像是否已更改。因此，只有在解析器进行插入/更新/删除并且站点访问图像时才会触摸图像表。访问和下载一张图像所需的时间约为 350 毫秒。

4

2 回答 2

3

你告诉我们两个问题：

  1. 导入很慢
  2. 浏览网站很慢

(2) 很简单：您可能需要了解您的读取查询并为它们编制索引。这绝对是可以解决的。

(1) 没有更多细节就很难说。我知道您需要比较很多 blob - 除了实际数据之外，您还可以存储这些博客的紧凑散列。这样您就不需要检索 blob 进行比较，甚至可以索引散列。

你应该在数据库中有图像吗？

最大的优点是：一致且简单的备份，开发人员的便利。最大的缺点是潜在的滥用。一般来说，您真的不能说图像属于文件系统。数据库通常对他们来说很好，除非有具体和具体的理由将他们放在其他地方。

我的猜测是您对这些博客的使用被误用了，如果文件存储在文件系统中，您也会遇到同样的问题。

于 2012-06-07T10:59:28.670 回答
0

你真的需要衡量性能在哪里伤害了你。如果不知道到底什么是慢的，你就不能指望开始修复它。

但是，如果您正在寻找从哪里开始测量的想法，那么我会说看看导入过程，看看它在 RBAR 样式中做了什么。RBAR 代表“Row By Agonizing Row”，它恰当地描述了在单行上运行的过程，而这些过程在集合中工作的效率要高得多。

我要检查的另一件事是，您实际上并没有检查每个图像的内容以确保它没有改变。如果您正在对该数据进行二进制比较，我可以想象它会非常缓慢。如果您为其计算校验和并比较校验和，则

a) 您可以在 SQL Server 进程之外计算该校验和，最好在另一个盒子上计算。
b) 您将能够在更精简的过程中检查更新的图像，特别是如果该校验和是INCLUDE合适索引上的列。

但是，正如评论的那样，将图像存储在数据库中并不是最聪明的想法。

于 2012-06-07T11:17:52.477 回答