关于大列的Mysql数据库问题

Question

我有一个有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万行左右，几个月后，而不是300.000-350.000行，我们将有1000万行用于存储这些PDF文件的文本版本的行。但是，我们将检索更少的页面，因此再次检索400页以发送Sphinx进行突出显示，我们可以检索5个页面，这将对性能产生很大影响。目前，当我们搜索一个术语并检索超过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文件的元数据与文件本身分开？你绝对不应该只有一张桌子。你可能想要表格pdf_info有100列（你真的有那么多的元数据吗？为什么有100列？）和pdf_files表的外键包含文件的实际文本。然后你可以试验，或许，制作info表innodb和files表myisam。

恕我直言：有很多很多理由不将你的pdf文件存储在mysql数据库中。我只是将文件路径存储到SAN或其他文件分发机制。 sql适用于存储任何抽象数据，文件肯定属于该类别。但文件系统专门用于存储文件，以及专门设计用于尽快为您提供这些文件的Web服务器。所以...只是想一想。

Answer 2

这听起来像是一个非常糟糕的技术选择。如果你可以减缓增长速度，那么你就可以把所有内容都保存在内存中（价格可以承受128GB左右）或者更大尺寸的分区，你基本上可以限制网络传输。

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

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

Answer 3

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