Scalabilità di 'sort -u' per file giganteschi

Qual è il limite di scalabilità ragionevole di 'sort -u'? (in dimensioni di "lunghezza della linea", "quantità di linee", "dimensione totale del file"?)

Qual è l'alternativa Unix per i file che superano questo in dimensione di "quantità di linee"? (Naturalmente posso facilmente implementarne uno, ma mi chiedevo se c'è qualcosa che può essere fatto con pochi comandi standard di Linux?)

sort

— Grzegorz Wierzowiecki
fonte

Per coloro che potrebbero voler cercare binariamente

— Grzegorz Wierzowiecki

Ci sono situazioni in cui un aiuto uniqprima sort -u. A proposito, per i dati ASCII si LC_ALL=C sortaccelera sortmoltissimo GNU (vedi questa risposta )

— Walter Tross,

Risposte:

Quello sortche trovi su Linux proviene dal pacchetto coreutils e implementa un'unione R-Way esterna . Suddivide i dati in blocchi che è in grado di gestire in memoria, li memorizza su disco e li unisce. I blocchi vengono eseguiti in parallelo, se la macchina dispone dei processori per questo.

Quindi, se ci fosse un limite, è lo spazio libero su disco che sortpuò utilizzare per archiviare i file temporanei che deve unire, combinato con il risultato.

— Anthon
fonte

Si noti che l'ordinamento GNU può comprimere quei file temporanei per comprimere ancora di più (e aumentare le prestazioni con dischi lenti).

— Stéphane Chazelas,

@ StéphaneChazelas Grazie per l'aggiornamento. Mi chiedevo se l'ordinamento fosse abbastanza intelligente da rimuovere i file di pezzi quando uno è completamente unito (cosa che potrebbe facilmente accadere se l'origine è già parzialmente ordinata) come ottimizzazione dello spazio. In questi giorni non ho tempo di immergermi nel codice sorgente :-(

— Anthon,

Oltre alla memoria c'è anche un altro limite che si applica alla fase di unione: il numero di file che possono essere aperti contemporaneamente. Questo è in genere un limite imposto dal sistema operativo. Anche l'ordinamento GNU fa fronte a questo, unendo ricorsivamente il numero di file che può aprire una volta sola!

— Diomidis Spinellis,

@ StéphaneChazelas Se stavo progettando uno strumento specifico per l'ordinamento di file molto grandi, memorizzerei le linee come indice nel file originale. GNU sort lo fa o usa semplicemente un algoritmo di compressione convenzionale?

— Casuale 832,

@ Random832 ed è pensato per essere in grado di sovrascrivere il file su se stesso ( sort -o file file)

— Stéphane Chazelas,

Non posso parlare per implementazioni specifiche del fornitore, ma l' UNIX sortimplementazione divide i file di grandi dimensioni in file più piccoli, ordina questi file e quindi combina i file più piccoli ordinati in un output ordinato aggregato.

L'unica limitazione è lo spazio su disco per i file più piccoli creati da intermedi da sort, ma i file possono essere reindirizzati a una directory arbitraria impostando la variabile di ambiente TMPDIR.

— Schily
fonte

Come si chiama esattamente l' implementazione dell'ordinamento UNIX ? È quello originale di Unix versione 3? La pagina man lì dice che non può ordinare i file più grandi di 128 KiB.

— Stéphane Chazelas,

Cosa capisci con Unix versione 3? La versione del 1973? L'implementazione originale dell'ordinamento UNIX è stata migliorata nel corso degli anni e IIRC, la versione Solaris è persino molto più veloce della versione GNU. Naturalmente, 25 anni fa l'ordinamento è stato migliorato per comprendere i caratteri multi-byte e ciò che ricordo da una discussione USENET, è stato che questo è stato fatto in modo efficiente su Solaris. A proposito: man largefileelenca sortcome file di grandi dimensioni a conoscenza.

— schily,

Quindi stai davvero parlando della versione specifica del fornitore Oracle di sort? O qualche derivato di qualche versione dell'ordinamento Unix AT&T? O qualsiasi versione certificata Unix di sort(come GNU sortsu OS / X)?

— Stéphane Chazelas,

La qualità delle sortimplementazioni moderne rispetto ai caratteri multi-byte può variare, il fatto che sortusi file intermedi divisi è comune a tutte le implementazioni UNIX basate sul codice originale. A proposito: la versione di Solaris è OSS come "OpenSolaris", vedi sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/…

— schily

25 anni fa, UTF-8 non è stato ancora inventato? Il supporto per le versioni locali UTF-8 è stato aggiunto in Solaris 7 ( 1 , 2 ). Ti riferisci a qualche altro set di caratteri multibyte?

— Stéphane Chazelas,

Basato su https://blog.mafr.de/2010/05/23/sorting-large-files/ e /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

Aggiornare:

Dalle risposte sopra vediamo che sortfa già ciò che è stato menzionato lo snippet, ovvero la fusione della R-Way esterna . Quindi, dopo tutto in esecuzione solo:

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

Dovrebbe essere sufficiente.

Le mie attuali assunzioni (senza controllo del codice) sui limiti sono:

la lunghezza massima della linea è limitata dalla quantità di memoria fisica. L'ordinamento deve contenere almeno due in memoria
quantità di righe - non ne sono a conoscenza
dimensione del file - ovviamente per filesystem
quantità di file aperti in parallelo - a seconda del sistema operativo (Grazie Diomidis Spinellis per averlo segnalato!)

(Questa risposta è contrassegnata come wiki della community : sentiti incoraggiato a migliorarla! :))

— Grzegorz Wierzowiecki
fonte

GNU sortordina in parallelo per impostazione predefinita (dal 2010 dopo quella pagina a cui ci si collega), --parallelè necessario ridurre il numero di thread simultanei invece di consentire di sortdeterminare quello ottimale. L'ordinamento fa già una divisione e l'unione internamente in un modo più efficiente. Dubito che questa suddivisione extra possa essere d'aiuto.

— Stéphane Chazelas,