1

我有一个有 100.000 行的表，很快它就会翻倍。数据库的大小目前为 5 GB，其中大部分位于一个特定列，即 PDF 文件的文本列。我们预计几个月后会有 20-30 GB 或 50 GB 的数据库，并且该系统将被频繁使用。

我有几个关于这个设置的问题

1-）我们在每个表上都使用innodb，包括用户表等。在这个表上使用myisam更好吗，我们存储PDF文件的文本版本？（从内存使用/性能角度）

2-) 我们使用 Sphinx 进行搜索，但是必须检索数据以突出显示。突出显示是通过 sphinx API 完成的，但我们仍然需要检索 10 行才能再次将其发送到 Sphinx。这 10 行可能会分配 50 mb 的内存，这是相当大的。所以我计划在数据库中将这些 PDF 文件分成 5 页的块，所以这 100.000 行将是大约 3-4 百万行，几个月后，我们将有 1000 万行，而不是 300.000-350.000 行行来存储这些 PDF 文件的文本版本。但是，我们将检索较少的页面，因此再次检索 400 页而不是发送 Sphinx 进行突出显示，我们可以检索 5 个页面，这将对性能产生很大影响。目前，当我们搜索一个词并检索超过 100 页的 PDF 文件时，执行时间为 0.3-0.35 秒，

你认为，这是一个很好的权衡吗？我们将拥有数百万行而不是 100k-200k 行，但它会节省内存并提高性能。这是解决这个问题的好方法吗？您对如何克服这个问题有任何想法吗？

数据的文本版本仅用于索引和突出显示。所以，我们非常灵活。

编辑：我们将 pdf 文件存储在我们的云中，但是对于搜索突出显示，我们需要检索 pdf 文件的文本版本并将其提供给 Sphinx，然后 Sphinx 返回突出显示的 256 个字符的文本。要索引 pdf 文件，我们需要将它们插入数据库，因为它们还有其他元数据，例如描述标签和标题，我们需要将它们链接到搜索引擎。如果我们从文件服务器索引 txt 文件或 pdf 文件，则无法从 db 中获取其他数据并将它们链接到搜索引擎上的那些 txt 文件。因此，我们仍然将 PDF 文件存储在我们的云中，但文本版本也必须在我们的数据库中，以便索引它们的标签标题和描述。它们是不同的表，但它也必须在数据库中。

谢谢，

4

3 回答 3

0

听起来您并不需要在每次点击该 pdf 文件的一行时都检索整个 pdf 文件。

您是否将有关 pdf 文件的元数据与文件本身分开？你绝对不应该在这里只有一张桌子。您可能想要pdf_info包含 100 列的表格（您真的有那么多元数据吗？为什么有 100 列？）以及pdf_files包含文件实际文本的表格的外键。然后您可以尝试制作info表 innodb 和files表 myisam。

恕我直言：不将 pdf 文件存储在 mysql 数据库中的原因有很多。我只会将文件路径存储到 SAN 或其他一些文件分发机制。sql 适合存储任何抽象数据，文件当然属于该类别。但是文件系统专门设计用于存储文件，而网络服务器专门设计用于尽快将这些文件交付给您。所以……只是想一想。

于 2010-04-17T10:36:11.223 回答
0

使用 Solr，可以使用数据库中的元数据索引文本文件。我已将搜索引擎切换到 Solr。

于 2010-04-20T03:40:20.743 回答
0

这听起来像是一个非常糟糕的技术选择。如果您可以减慢增长速度，以便将所有内容保存在内存中（可以承受到 128GB 左右）或更大的分区，则基本上可以限制网络传输。

[编辑] 如果 pdf 在磁盘上，而不是在 ram 中，则需要访问您的磁盘。如果您没有 SSD，则可以执行 50 次/秒/磁盘。只要 pdf 小于磁盘磁道，拆分就不是很有趣。如果您拆分 pdf，然后需要访问所有部分，则可能需要从多个轨道加载，这会大大降低您的速度。

在多用户设置中使用 RDBM 处理大型文档并不是一个好主意，性能方面。

于 2010-04-17T10:36:57.837 回答