「sort -u」の合理的なスケーラビリティ制限とは何ですか？（「行の長さ」、「行の量」、「ファイルの合計サイズ」の次元で？）
「行数」の次元でこれを超えるファイルに対するUnixの代替手段は何ですか？（もちろん、1つを簡単に実装できますが、標準のLinuxコマンドをほとんど使用せずにできることはあるのでしょうか？）
回答:
sortあなたがLinux上で見つけることがから来ているのcoreutilsのパッケージと実装外部R-ウェイマージ。データをメモリに処理できるチャンクに分割し、ディスクに保存してからマージします。マシンにプロセッサが搭載されている場合、チャンクは並行して実行されます。
そのため、制限がある場合は、sortマージする必要がある一時ファイルを保存するために使用できる空きディスク領域が、結果と組み合わされます。
sort -o file file）
ベンダー固有の実装について話すことはできませんが、UNIX sort実装は大きなファイルを小さなファイルに分割し、これらのファイルをソートしてから、ソートされた小さなファイルを集約ソート出力に結合します。
唯一の制限は、によって中間的に作成された小さいファイルのディスク容量sortですが、環境変数を設定することにより、ファイルを任意のディレクトリにリダイレクトできますTMPDIR。
man largefileリストsortします。
sortですか？または、AT＆T Unixソートのバージョンの派生物はありますか？または、Unix認定バージョンsort（sortOS / X上のGNUなど）
sortマルチバイト文字に関する最新の実装の品質は異なる場合があります。sort分割された中間ファイルを使用するという事実は、元のコードに基づくすべてのUNIX実装に共通です。ところで：Solarisバージョンは、「OpenSolarisの」などのOSSで、参照sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/...
https://blog.mafr.de/2010/05/23/sorting-large-files/および/unix//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
十分なはずです。
制限に関する私の現在の仮定（コードをチェックせず）は次のとおりです。
（この回答はコミュニティwikiとしてマークされています -それを改善することをお勧めし！:)）
sortデフォルトで並行してソートします（リンクしているページの2010年以降）ので、最適な--parallelスレッドをsort決定するのではなく、並行スレッドの数を減らす必要があります。ソートはすでに、より効率的な方法で内部的に分割とマージを行っています。余分な分割が役立つとは思えません。