Mysql数据库关于大列的问题

Question

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

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

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

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

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

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

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

谢谢，

Answer 1

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

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

恕我直言:有很多很多理由不将您的 pdf 文件存储在 mysql 数据库中。我只是将文件路径存储到 SAN 或其他一些文件分发机制。 sql 适合存储任何抽象数据，文件当然属于这一类。但是文件系统是专门为存储文件而设计的，而网络服务器是专门为尽快将这些文件交付给您而设计的。所以...只是需要考虑一下。