Строки вида крупного файла количеством слов на строке (идеально параллельно)

Я работаю над общественным алгоритмом обнаружения для анализа данных социальной сети из Facebook. Первая задача, обнаруживая все клики в графике, может быть сделана эффективно параллельно и оставляет меня с выводом как это:

17118 17136 17392
17064 17093 17376
17118 17136 17356 17318 12345
17118 17136 17356 17283
17007 17059 17116

Каждая из этих строк представляет уникальную клику (набор идентификаторов узла), и я хочу отсортировать эти строки в порядке убывания по количеству идентификаторов на строку. В случае примера выше, вот то, на что должен быть похожим вывод:

17118 17136 17356 17318 12345
17118 17136 17356 17283
17118 17136 17392
17064 17093 17376
17007 17059 17116

(Связи---т.е. строки с тем же количеством идентификаторов---могут быть отсортированы произвольно.)

Что является самым эффективным способом отсортировать эти строки.

Помните о следующих моментах:

1. Файл, который я хочу отсортировать, мог быть больше, чем физическая память машины
2. Большинство машин, что я работаю на этом, имеет несколько процессоров, таким образом, параллельное решение было бы идеально
3. Идеальное решение просто было бы сценарием оболочки (вероятно, использующий вид), но я открыт для простых решений в Python или жемчуге (или любой язык, пока это делает задачу простой),
4. Эта задача находится в некотором смысле очень легкий---, я только ищу любое старое решение, а скорее для простого и прежде всего эффективного решения

ОБНОВЛЕНИЕ 2: Лучшее решение

На основе сравнительного тестирования решений сделал предложение (см. ниже), вот лучшее решение (взятый от Vlad, который в свою очередь адаптировал его из других решений, предложенных здесь). Это довольно умно и даже не использует вид

for FILE in infile.* ; do
  awk '{ print >sprintf("tmpfile.%05d.%s", NF, FILE) }' \
    FILE=`basename $FILE` $FILE&
done
wait
ls -1r tmpfile.* | xargs cat >outfile
rm -f tmpfile.*

ОБНОВЛЕНИЕ 1: Сравнительное тестирование результатов предлагаемых решений

Для сравнительного тестирования я взял Клики, найденные в сети Oklahoma State Facebook. Неотсортированные файлы, которые содержат эти клики взгляд точно так же, как первый пример, который я показываю выше, содержу 46 362 546 строк, который приносит размеру файла до 6,4 ГБ. Клики почти равномерно распространены по 8 файлам. Система, на которой я тестирую это, содержит 4 физических процессора, каждого с 6 ядрами и 12 МБ кэш L2, для в общей сложности 24 ядер. Это также содержит 128 ГБ физической памяти. Поскольку строки, которые будут отсортированы, были разделены на 8 файлов, большинство этих решений использовало 8 (или 16) параллельные процессы.

Игнорируя первый наивный подход, я сравнил последних 5 предложений Vlad Romascanu (решение, которое я выбрал).

Первое решение не было слишком эффективно:

real    6m35.973s
user    26m49.810s
sys     2m14.080s

Я пытался использовать решения 2, 3, и 4, которые используют файлы FIFO, но каждый из них только использовал один процесс вида и таким образом требовался много времени (и таким образом, я уничтожил их, прежде чем они могли закончить) /

Последнее решение было самым быстрым:

real    1m3.272s
user    1m21.540s
sys     1m22.550s

Обратите внимание, что пользовательское время этого решения является 1m21 s, намного лучше, чем первые решения 26 минут.