关于大型列的Mysql数据库问题

我有一张10万行的桌子，很快就会翻倍。该数据库的大小目前为5 gb，其中大多数都位于一个特定列，即PDF文件的文本列。我们预计在两个月后将有20-30GB或可能50GB的数据库，该系统将被频繁使用

关于此设置，我有几个问题

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

2-）我们使用Sphinx进行搜索，但是必须检索数据以突出显示。高亮显示是通过sphinx API完成的，但我们仍然需要检索10行，以便再次将其发送到sphinx。这10行可能会分配50MB内存，这相当大。所以我计划在数据库中将这些PDF文件分为5页，这样10万行将约为300-400万行，几个月后，我们将有1000万行存储这些PDF文件的文本版本，而不是300.000-350.000行。但是，我们将检索较少的页面，因此我们可以检索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文件，但文本版本也必须在数据库中，以便为它们的标签标题和描述编制索引。它们是不同的表，但也必须在数据库中

---

谢谢，

听起来你不需要每次点击一行来检索整个pdf文件

您是否将pdf文件的元数据与文件本身分离？你绝对不应该只有一张桌子。您可能需要像table

pdf\u info

这样的东西，它有100列（您真的有那么多元数据吗？为什么有100列？）和一个包含文件实际文本的

pdf\u文件的外键。然后，您可以尝试将
info
表制作成innodb和
文件
表myisam

IMHO：有很多很多理由不将pdf文件存储在mysql数据库中。我只是将文件路径存储到SAN或其他文件分发机制。sql很适合存储任何抽象数据，文件当然属于这一类。但文件系统是专门为存储文件而设计的，而Web服务器是专门为尽快向您提供这些文件而设计的。所以只是想一想。
这听起来是一个非常糟糕的技术选择。如果您可以减缓增长速度，以便将所有内容都保留在内存中（128GB左右的价格可以承受），或者将分区保留在更大的大小上，则基本上可以限制网络传输

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

在多用户设置中使用RDBMs处理大型文档在性能方面不是一个好主意。
使用Solr，可以使用数据库中的元数据索引文本文件。我已将搜索引擎切换到Solr。
您将同时拥有多少用户？我们预计在前6个月内每天有30万页面浏览量。我们在云端存储pdf文件，但为了突出显示搜索，我们需要检索pdf文件的文本版本并将其交给Sphinx，然后，Sphinx返回高亮显示的256个字符的文本。为了索引pdf文件，我们需要将它们插入数据库中，因为它们还有额外的元数据，如描述标签和标题，我们需要为搜索引擎链接它们。如果我们从文件服务器索引txt文件或pdf文件，则无法从数据库获取其他数据并将其链接到搜索引擎上的txt文件。如果这是一个错误的选择，您有什么建议吗？哦，对不起，您的意思是分裂是一个错误的选择。是的，如果我们为我们的DB服务器和web服务器购买足够的ram，就不会有任何问题，但从长远来看，数据可能会增长得过大，因此如果有一种优雅的方法来解决这个问题，我很想听听。否则，如果拆分不能解决这个问题，我们将购买大量ram。