Khả năng mở rộng của 'sort -u' cho các tệp khổng lồ


23

Giới hạn khả năng mở rộng hợp lý của 'sort -u' là gì? (theo kích thước của "chiều dài dòng", "số lượng dòng", "tổng kích thước tệp"?)

Unix thay thế cho các tập tin vượt quá mức này theo "số lượng dòng" là gì? (Tất nhiên tôi có thể dễ dàng thực hiện một, nhưng tôi tự hỏi liệu có điều gì có thể được thực hiện với một vài lệnh Linux tiêu chuẩn không?)


Đối với những người có thể muốn tìm kiếm nhị phân trong đó hoặc biết cách: unix.stackexchange.com/q/247508/9689
Grzegorz Wierzowiecki

2
Có những tình huống mà uniqtrước khi sort -ugiúp đỡ. BTW, đối với dữ liệu ASCII LC_ALL=C sorttăng tốc GNU sortrất nhiều (xem câu trả lời này )
Walter Tross

Câu trả lời:


39

Cái sortmà bạn tìm thấy trên Linux đến từ gói coreutils và thực hiện hợp nhất R-Way bên ngoài . Nó chia dữ liệu thành các khối mà nó có thể xử lý trong bộ nhớ, lưu trữ chúng trên đĩa và sau đó hợp nhất chúng lại. Các khối được thực hiện song song, nếu máy có bộ xử lý cho điều đó.

Vì vậy, nếu có giới hạn, đó là không gian đĩa trống sortcó thể sử dụng để lưu trữ các tệp tạm thời mà nó phải hợp nhất, kết hợp với kết quả.


3
Lưu ý rằng sắp xếp GNU có thể nén các tệp tạm thời đó để đóng gói nhiều hơn (và tăng hiệu suất với các đĩa chậm).
Stéphane Chazelas

1
@ StéphaneChazelas Cảm ơn bạn đã cập nhật. Tôi đã tự hỏi liệu sắp xếp có đủ thông minh để loại bỏ các tệp chunk khi một tệp được hợp nhất hoàn toàn (điều này có thể dễ dàng xảy ra nếu nguồn đã được sắp xếp một phần) như là một tối ưu hóa không gian. Tôi không có thời gian để đi sâu vào mã nguồn những ngày này :-(
Anthon

3
Ngoài bộ nhớ còn có một giới hạn khác áp dụng cho pha hợp nhất: số lượng tệp có thể được mở đồng thời. Đây thường là một giới hạn được áp đặt bởi hệ điều hành. GNU sắp xếp đối phó với điều đó, bằng cách hợp nhất đệ quy số lượng tệp mà nó có thể mở cùng một lúc!
Diomidis Spinellis

@ StéphaneChazelas Nếu tôi đang thiết kế một công cụ dành riêng cho việc sắp xếp các tệp rất lớn, tôi sẽ lưu trữ các dòng dưới dạng một chỉ mục vào tệp gốc. GNU sort có làm điều này không, hay nó chỉ đơn giản là sử dụng thuật toán nén thông thường?
Random832

3
@ Random832 và nó có nghĩa là có thể ghi đè lên tệp ( sort -o file file)
Stéphane Chazelas

1

Tôi không thể nói về các triển khai cụ thể của nhà cung cấp, nhưng việc UNIX sorttriển khai chia các tệp lớn thành các tệp nhỏ hơn, sắp xếp các tệp này và sau đó kết hợp các tệp nhỏ hơn được sắp xếp thành một đầu ra được sắp xếp tổng hợp.

Giới hạn duy nhất là không gian đĩa cho các tệp nhỏ hơn được tạo trung gian sort, nhưng các tệp có thể được chuyển hướng đến một thư mục tùy ý bằng cách đặt biến môi trường TMPDIR.


3
Chính xác thì bạn gọi triển khai sắp xếp UNIX là gì? Đây có phải là bản gốc từ Unix phiên bản 3 không? Trang người đàn ông ở đó nói rằng nó không thể sắp xếp các tệp lớn hơn 128KiB.
Stéphane Chazelas

Bạn hiểu gì về phiên bản Unix 3? Phiên bản từ năm 1973? Việc triển khai sắp xếp UNIX ban đầu đã được cải tiến qua nhiều năm và IIRC, phiên bản Solaris thậm chí còn nhanh hơn phiên bản GNU. Tất nhiên, 25 năm trước đã được tăng cường để hiểu các ký tự nhiều byte và điều tôi nhớ từ một cuộc thảo luận USENET, là điều này đã được thực hiện hiệu quả trên Solaris. BTW: man largefileliệt kê sortnhư nhận biết tệp lớn.
schily

2
Vì vậy, bạn đang thực sự nói về phiên bản cụ thể của nhà cung cấp Oracle sort? Hoặc bất kỳ dẫn xuất nào của một số phiên bản sắp xếp của AT & T Unix? Hoặc bất kỳ phiên bản được chứng nhận Unix nào của sort(như GNU sorttrên OS / X)?
Stéphane Chazelas

Chất lượng của các sorttriển khai hiện đại liên quan đến ký tự nhiều byte có thể khác nhau, thực tế là việc sortsử dụng các tệp trung gian phân tách là phổ biến đối với tất cả các triển khai UNIX dựa trên mã gốc. BTW: phiên bản Solaris là OSS là "OpenSolaris", xem sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/
đấm

25 năm trước, UTF-8 chưa được phát minh? Hỗ trợ cho các địa điểm UTF-8 đã được thêm vào trong Solaris 7 ( 1 , 2 ). Bạn đang đề cập đến một số bộ ký tự đa nhân khác?
Stéphane Chazelas

1

Dựa trên 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

Cập nhật:

Từ các câu trả lời ở trên, chúng tôi thấy rằng sortđã thực hiện những gì đã đề cập đoạn trích - tức là hợp nhất R-Way bên ngoài . Vì vậy, sau khi tất cả chạy chỉ:

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

Nên là đủ.

Các giả định hiện tại của tôi (không kiểm tra mã) về các giới hạn là:

  • chiều dài dòng tối đa được giới hạn bởi số lượng bộ nhớ vật lý. Sắp xếp cần phải phù hợp với ít nhất hai vào bộ nhớ
  • số lượng dòng - tôi không biết
  • kích thước tệp - tất nhiên theo hệ thống tập tin
  • số lượng tệp được mở song song - tùy thuộc vào Hệ điều hành (Cảm ơn Diomidis Spinellis đã chỉ ra điều này!)

(Câu trả lời này được đánh dấu là wiki cộng đồng - cảm thấy được khuyến khích để cải thiện nó! :))


2
GNU sortsắp xếp song song theo mặc định (kể từ năm 2010 sau trang đó bạn đang liên kết đến), --parallelphải giảm số lượng luồng đồng thời thay vì để sortxác định mức tối ưu. Sắp xếp đã thực hiện phân tách và hợp nhất nội bộ theo cách hiệu quả hơn. Tôi nghi ngờ làm thêm rằng chia tách sẽ giúp.
Stéphane Chazelas
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.