mysql - 优化 MySQL 与许多平面文件和 HDD 利用率

Question

我想运行一个机器学习算法作为我的残局研究代码，该代码迄今为止未经证实且未发布用于文本挖掘目的。文本已经获得，但从 Common Crawl 获得的 warc 格式中被删除。我正在为机器学习目的准备数据，其中一项理想的分析任务是在启动到 ML 应用程序之前对语料库进行 IDF 逆文档频率分析。

据我了解，要让 IDF 发挥作用，每个文件都应该代表一位演讲者或一个想法 - 通常是一段不比推文长多少的 ascii 文本。挑战在于我已经抓取了大约 1500 万个文件。我在 Windows 7 上使用 Strawberry Perl 来读取每个文件并拆分文档中包含的标签，以便来自相关社交媒体的每个评论都落入数组的一个元素中(并且在更强类型的语言中将是字符串类型)。

从这里开始，我遇到了性能问题。我让我的脚本运行了一整天，它只在 24 小时内完成了 400,000 个输入文件。从这些输入文件中，它产生了大约 200 万个输出文件，代表每个发言者一个文件，使用 Perl 的 HTML::Strip 模块进行 html 剥离文本。当我查看我的系统时，我发现我的本地数据驱动器上的磁盘利用率非常高 - 有大量的 ASCII 文本写入，远小于 1 KB，每个都被塞进我本地数据驱动器的一个 1 KB 扇区中NTFS 格式的硬盘。

是否值得尝试停止运行，在我的家庭系统上设置一个 MySQL 数据库，在数据库中设置一个最大长度可能为 500-1000 个字符的文本字段，然后重新运行 perl 脚本，这样它slurps 一个输入的 html 文件，拆分它，HTML 剥离它，然后准备并执行一个字符串插入 vs 一个数据库表？

一般来说，从大量单个文本文件的文件输出格式切换到大量数据库插入的格式在我的硬盘驱动器上更容易/从长远来看写得更快，因为DBMS 中的某些缓存或 RAM/磁盘空间利用魔法？

Answer 1

文件系统可以解释为分层键值存储，它经常被 Unix-ish 程序使用。但是，创建文件可能会有些昂贵，这还取决于您使用的操作系统和文件系统。特别是，不同的文件系统在访问时间如何随一个目录中的文件数量变化方面存在显着差异。例如。见NTFS performance and large volumes of files and directories和 How do you deal with lots of small files? : “一个目录中有 10,000 个文件后，NTFS 性能会严重下降。”

因此，从使用数百万个小文件的伪数据库迁移到“真实”数据库(例如将数据存储在单个文件中的 SQLite)，从而降低访问单个记录的成本，您可能会看到显着的好处。

另一方面，200 万条记录并不算多，这表明文件系统开销可能不是您的限制因素。考虑在测试工作负载下运行您的软件，并使用分析器或其他调试工具来查看时间花在了哪里。真的是open()耗费了这么多时间吗？或者是否有其他可以优化的昂贵处理？如果有一个可以并行化的预处理步骤，那么仅此一项就可以显着缩短处理时间。