Ý nghĩa hiệu suất cho hàng triệu tệp trong một hệ thống tệp hiện đại là gì?

Giả sử chúng tôi đang sử dụng ext4 (đã bật dir_index) để lưu trữ xung quanh các tệp 3M (với kích thước trung bình 750KB) và chúng tôi cần quyết định lược đồ thư mục nào chúng tôi sẽ sử dụng.

Trong giải pháp đầu tiên , chúng tôi áp dụng hàm băm cho tệp và sử dụng thư mục hai cấp (là 1 ký tự cho cấp thứ nhất và 2 ký tự cho cấp thứ hai): do đó, filex.forhàm băm bằng với abcde1234 , chúng tôi sẽ lưu trữ trên / path / a / bc /abcde1234-filex.for.

Trong giải pháp thứ hai , chúng tôi áp dụng hàm băm cho tệp và sử dụng thư mục hai cấp (là 2 ký tự cho cấp thứ nhất và 2 ký tự cho cấp thứ hai): do đó, filex.forhàm băm bằng với abcde1234 , chúng tôi sẽ lưu trữ trên / path / ab / de /abcde1234-filex.for.

Đối với giải pháp đầu tiên, chúng tôi sẽ có sơ đồ sau /path/[16 folders]/[256 folders]với trung bình 732 tệp cho mỗi thư mục (thư mục cuối cùng, nơi tệp sẽ nằm).

Trong khi trên các giải pháp thứ hai, chúng tôi sẽ phải /path/[256 folders]/[256 folders]có một trung bình của 45 tác phẩm cho mỗi thư mục .

Xem xét chúng ta sẽ ghi / hủy liên kết / đọc tệp ( nhưng chủ yếu là đọc ) từ lược đồ này rất nhiều (về cơ bản là hệ thống bộ đệm nginx), liệu nó có làm mờ đi, theo nghĩa hiệu suất, nếu chúng ta chọn một hoặc một giải pháp khác?

Ngoài ra, các công cụ chúng ta có thể sử dụng để kiểm tra / kiểm tra thiết lập này là gì?

Lý do người ta sẽ tạo ra loại cấu trúc thư mục này là các hệ thống tệp phải định vị một tệp trong một thư mục và thư mục càng lớn thì hoạt động đó càng chậm.

Làm thế nào chậm hơn bao nhiêu tùy thuộc vào thiết kế hệ thống tập tin.

Hệ thống tập tin ext4 sử dụng cây B để lưu các mục nhập thư mục. Việc tra cứu trên bảng này dự kiến ​​sẽ mất thời gian O (log n) , phần lớn thời gian ít hơn bảng tuyến tính ngây thơ mà ext3 và các hệ thống tệp trước đó đã sử dụng (và khi không, thư mục này quá nhỏ so với thực sự quan trọng).

Hệ thống tập tin XFS sử dụng cây B + thay thế. Ưu điểm của điều này so với bảng băm hoặc cây B là bất kỳ nút nào cũng có thể có nhiều con b , trong đó XFS b thay đổi và có thể cao tới 254 (hoặc 19 đối với nút gốc; và các số này có thể đã hết hạn ). Điều này cung cấp cho bạn độ phức tạp thời gian của O (log _b n) , một cải tiến lớn.

Một trong hai hệ thống tệp này có thể xử lý hàng chục ngàn tệp trong một thư mục, với XFS nhanh hơn đáng kể so với ext4 trên một thư mục có cùng số lượng nút. Nhưng bạn có thể không muốn có một thư mục duy nhất có in 3M, vì ngay cả với cây B +, việc tra cứu có thể mất một thời gian. Đây là những gì dẫn đến việc tạo các thư mục theo cách này ở nơi đầu tiên.

Đối với các cấu trúc đề xuất của bạn, tùy chọn đầu tiên bạn đưa ra chính xác là những gì được hiển thị trong các ví dụ nginx. Nó sẽ hoạt động tốt trên cả hai hệ thống tập tin, mặc dù XFS vẫn sẽ có một chút lợi thế. Tùy chọn thứ hai có thể hoạt động tốt hơn một chút hoặc kém hơn một chút, nhưng có lẽ nó sẽ khá gần, ngay cả trên điểm chuẩn.

Theo kinh nghiệm của tôi, một trong những yếu tố mở rộng là kích thước của các nút được đưa ra một chiến lược phân vùng tên băm.

Cả hai tùy chọn được đề xuất của bạn tạo tối đa ba mục nhập cho mỗi tệp được tạo. Ngoài ra, 732 tệp sẽ tạo ra một nút vẫn còn ít hơn 16KB thông thường. Đối với tôi, điều này có nghĩa là một trong hai tùy chọn sẽ thực hiện như nhau.

Tôi hoan nghênh bạn về hàm băm ngắn của bạn; các hệ thống trước đây tôi đã làm việc đã lấy sha1sum của tệp đã cho và các thư mục được ghép dựa trên chuỗi đó, một vấn đề khó khăn hơn nhiều.

Chắc chắn một trong hai tùy chọn sẽ giúp giảm số lượng tệp trong một thư mục xuống một cái gì đó có vẻ hợp lý, cho xfs hoặc ext4 hoặc bất kỳ hệ thống tệp nào. Không rõ cái nào tốt hơn, sẽ phải kiểm tra để nói.

Điểm chuẩn với ứng dụng của bạn mô phỏng một cái gì đó như khối lượng công việc thực sự là lý tưởng. Nếu không, hãy đến với một cái gì đó mô phỏng nhiều tệp nhỏ cụ thể. Nói về điều đó, đây là một nguồn mở gọi là smallfile . Tài liệu của nó tham khảo một số công cụ khác.

hdparmlàm I / O duy trì không hữu ích. Nó sẽ không hiển thị nhiều mục I / O nhỏ hoặc thư mục khổng lồ được liên kết với rất nhiều tệp.

Một trong những vấn đề là cách quét thư mục.

Hãy tưởng tượng phương thức Java chạy quét trên thư mục.

Nó sẽ phải phân bổ số lượng lớn bộ nhớ và phân bổ nó trong khoảng thời gian ngắn, điều này rất nặng nề đối với JVM.

Cách tốt nhất là sắp xếp cấu trúc thư mục theo cách mà mỗi tệp nằm trong thư mục chuyên dụng, ví dụ: năm / tháng / ngày.

Cách quét toàn bộ được thực hiện là đối với mỗi thư mục có một lần chạy chức năng để JVM sẽ thoát khỏi chức năng, giải phóng RAM và chạy lại nó trên một thư mục khác.

Đây chỉ là ví dụ nhưng dù sao có thư mục lớn như vậy cũng không có ý nghĩa gì.

Tôi đã có cùng một vấn đề. Cố gắng lưu trữ hàng triệu tệp trong máy chủ Ubuntu trong ext4. Đã kết thúc chạy điểm chuẩn của riêng tôi. Phát hiện ra rằng thư mục phẳng thực hiện cách tốt hơn trong khi sử dụng đơn giản hơn:

Đã viết một bài báo .