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

时间:2019-01-16 06:38:05

标签: mysql perl optimization text

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

我的理解是,要使IDF起作用,每个文件应代表一个发言人或一个想法-通常是一段简短的ascii文本,其长度不超过一条tweet。面临的挑战是,我已经抓取了大约1500万个文件。我在Windows 7上使用Strawberry Perl读取每个文件,并拆分文档中包含的标签,以使来自相关社交媒体的每个评论都落入数组的元素中(并且使用更强类型的语言是类型的字符串)。

从这里我遇到了性能问题。我已经让我的脚本全天运行,并且在24小时内仅通过400,000个输入文件完成了脚本。从这些输入文件中,产生了大约200万个输出文件,每个人使用Perl的HTML :: Strip模块将html剥离文本的一个文件表示为一个文件。当我查看系统时,我发现本地数据驱动器上的磁盘利用率非常高-大量的ASCII文本写入,远小于1 KB,每个写入到本地的1 KB扇区中NTFS格式的HDD。

是否应该停止运行,在我的家庭系统上设置MySQL数据库,在数据库中设置最大长度为500-1000个字符的文本字段,然后重新运行perl脚本,这样是否值得?抓取一个输入的html文件,对其进行拆分,对其进行HTML剥离,然后准备并执行一个字符串插入与数据库表的比较?

总的来说,由于文件输出格式从大量单个文本文件转换为大量数据库插入格式,因此在我的硬盘驱动器上更容易/从长远来看,写入速度更快,这是由于DBMS中有一些缓存或RAM /磁盘空间利用魔术吗?

2 个答案:

答案 0 :(得分:4)

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

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

另一方面,200万条记录并不多,这表明文件系统开销可能不是您的限制因素。考虑在测试工作负载下运行软件,并使用探查器或其他调试工具来查看时间。 open()真的需要那么多时间吗?还是有其他可以优化的昂贵工艺?如果存在可以并行化的预处理步骤,则仅此一项就可以大大缩短处理时间。

答案 1 :(得分:1)

如何!

几年前,流行的cms出现了很多问题。平原地区大多表现良好。但是,当旁通行内联也出现时,它就会下降。

所以我写了一些丑陋的台词来寻找最快的方法。请注意,资源设置了不同的限制!

1st)我花时间建立了一个直接的可解决点。每个人都有自己的一组平面文件。

2nd)我做了一个Ramdisk。确保您有足够的项目资源!

3rd)对于备份,我使用了rsync和renundance,将其压缩/提取到了tar.gz中的Ramdisk中

实际上,最快的方法是。时间码的转换和生成递归文件夹结构非常简单。也可以读取,写入,替换,删除。

最终版本导致来自以下方面的处理:

PHP / MySQL> 5秒 Perl / HDD〜1.2秒 Perl / RamDisk〜0.001秒

当我看到您在做什么时,此构造可能对您有用。我不知道您的项目的内部结构。

硬盘使用寿命更长,可以通过直接寻址来优化您的工作流程。它可以从其他阶段访问。会说,您也可以在其他脚本的基础上工作。正如您所相信的那样,R中的数据处理,shell的通知程序或其他任何东西……

不再需要像MySQL这样的缓冲错误。您的CPU不再循环noop。