python - 使用 Python 处理许多文件

Question

任务:

我正在处理 4 TB 的数据/文件，存储在外部 USB 磁盘上:图像、html、视频、可执行文件等。

我想使用以下模式在 sqlite3 数据库中索引所有这些文件:

path TEXT, mimetype TEXT, filetype TEXT, size INT

到目前为止:

我 os.walk 递归地遍历挂载的目录，使用 python 的子进程执行 linux file 命令并使用 os.path.getsize() 获取大小。最后将结果写入数据库，存储在我的电脑上——usb当然是用-o ro挂载的。顺便说一句，没有线程

您可以在此处查看完整代码 http://hub.darcs.net/ampoffcom/smtid/browse/smtid.py

问题:

代码真的很慢。我意识到 direcory 结构越深，代码越慢。我想，os.walk 可能是个问题。

问题:

1. 是否有比 os.walk 更快的替代方案？
2. 线程会固定东西吗？

Answer 1

Is there a faster alternative to os.walk?

是的。事实上，多个。

• scandir (将在 3.5 中的标准库中)比 walk 快得多。
• C 函数 fts比 scandir 快得多。我很确定 PyPI 上有包装器，虽然我不知道有什么值得推荐的，而且通过 ctypes 或 cffi 使用它并不难，如果你知道任何 C。
• find工具使用 fts，如果您不能直接使用 fts，您可以随时对其进行子处理。

---

Would threading fasten things up?

这取决于我们没有的系统详细信息，但是……您将所有时间都花在等待文件系统上。除非你有多个独立的驱动器，它们只在用户级别绑定(bind)在一起(也就是说，不是 LVM 或它下面的东西，比如 RAID)或者根本没有(例如，一个只是安装在另一个的文件系统下)，并行发出多个请求可能不会加快速度。

不过，这还是很容易测试的；为什么不试试看呢？

---

还有一个想法:您可能会花费大量时间生成这些 file 进程并与之通信。有多个 Python 库使用相同的 libmagic它确实如此。我不想特别推荐其中一个，所以这里是 search results .

---

正如 monkut 所建议的，确保您正在执行批量提交，而不是使用 sqlite 自动提交每个插入。作为the FAQ explains , sqlite 每秒可以执行约 50000 次插入，但每秒只能执行几十个事务。

当我们这样做时，如果您可以将 sqlite 文件放在与您正在扫描的文件系统不同的文件系统上(或者将其保存在内存中直到完成，然后将其一次性全部写入磁盘)，这可能值得一试。

---

最后但也是最重要的:

• 分析您的代码以查看热点在哪里，而不是猜测。
• 创建小型数据集并对不同的备选方案进行基准测试，看看您能获得多少 yield 。