☰

巨大文件的“sort -u”的可扩展性

tag-icon • tag-icon performance sort
巨大文件的“sort -u”的可扩展性

合理的可扩展性限制是多少sort -u？ （以“行长度”、“行数”、“文件总大小”为单位）

对于“行数”超过此尺寸的文件，Unix 的替代方案是什么？

当然，我可以轻松实现一个，但我想知道是否有一些东西可以用很少的标准 Linux 命令来完成。

答案1

这sort来自核心工具封装并实现一个外部 R-Way 合并。它将数据分割成可以在内存中处理的块，将它们存储在磁盘上，然后合并它们。如果机器具有相应的处理器，则这些块是并行完成的。

因此，如果有限制的话，那就是sort可用磁盘空间来存储必须合并的临时文件以及结果。

答案2

我不能谈论供应商特定的实现，但该UNIX sort实现将大文件拆分为较小的文件，对这些文件进行排序，然后将排序的较小文件组合成聚合的排序输出。

唯一的限制是中间创建的较小文件的磁盘空间sort，但可以通过设置环境变量将文件重定向到任意目录TMPDIR。

答案3

基于https://blog.mafr.de/2010/05/23/sorting-large-files/和https://unix.stackexchange.com/a/88704/9689:

split -n l/20 input input-
for inpf in input-* ; do
    sort --parallel="$(nproc --all)" "${inpf}" > sorted-"{$inpf}"
done
sort -m sorted-input-* > sorted-input

更新：

从上面的答案我们看到sort已经做了提到的片段 - 即外部 R-Way 合并。所以毕竟运行只是：

sort --parallel="$(nproc --all)" -u input > output

应该足够了。

我当前关于限制的假设（不检查代码）是：

  • 最大行长度受物理内存量的限制。排序需要至少将两个放入内存
  • 行数 - 我不知道
  • 文件大小 - 当然由文件系统决定
  • 并行打开的文件数量 - 取决于操作系统（谢谢迪奥米迪斯·斯皮内利斯指出这一点！）

（这个答案被标记为社区维基- 受到鼓励去改进它！ :) ）

相关内容