Làm cách nào để tôi lưu trữ và phục vụ hiệu quả nhất 1.000.000+ tệp được nén trên máy chủ web Linux?


10

Tôi có nội dung tĩnh lớn mà tôi phải phân phối thông qua máy chủ web dựa trên Linux. Nó là một tập hợp hơn một triệu tệp gzip nhỏ. 90% các tệp nhỏ hơn 1K và các tệp còn lại nhiều nhất là 50K. Trong tương lai, điều này có thể tăng lên hơn 10 triệu tệp gzip.

Tôi có nên đặt nội dung này trong cấu trúc tệp hay tôi nên xem xét đưa tất cả nội dung này vào cơ sở dữ liệu? Nếu nó nằm trong cấu trúc tệp, tôi có thể sử dụng các thư mục lớn hay tôi nên xem xét các thư mục nhỏ hơn?

Tôi được cho biết một cấu trúc tệp sẽ nhanh hơn để phân phối, nhưng mặt khác, tôi biết rằng các tệp sẽ chiếm nhiều dung lượng trên đĩa, vì các khối tệp sẽ nhiều hơn 1K.

Chiến lược tốt nhất về hiệu suất giao hàng là gì?

CẬP NHẬT

Đối với các bản ghi, tôi đã thực hiện một thử nghiệm trong Windows 7, với nửa triệu tệp:

nhập mô tả hình ảnh ở đây

Câu trả lời:


6

Tôi đoán rằng cấu trúc FS sẽ nhanh hơn, nhưng bạn sẽ cần một cấu trúc thư mục tốt để tránh có các thư mục có số lượng tệp rất lớn.

Tôi sẽ không lo lắng quá nhiều về không gian đĩa bị mất. Ví dụ, ở kích thước khối 16K, bạn sẽ mất 15 GB dung lượng trong trường hợp xấu nhất khi bạn cần thêm một khối cho mỗi tệp. Với kích thước đĩa ngày nay, không có gì và bạn có thể điều chỉnh các tham số của hệ thống tệp cho nhu cầu cụ thể của mình.


5

Nếu bạn chọn tùy chọn cấu trúc tệp, một điều bạn có thể làm để cải thiện hiệu suất I / O của đĩa ít nhất ở một mức độ nào đó là gắn kết phân vùng với noatime + gật đầu trừ khi bạn phải có chúng. Chúng không thực sự quan trọng chút nào vì vậy tôi khuyên bạn nên làm điều đó. Có lẽ bạn cũng có thể sử dụng một ổ đĩa trạng thái rắn.


4

Tôi nghĩ rằng câu trả lời chính xác ở đây phụ thuộc vào cách các tệp sẽ được lập chỉ mục ... điều gì xác định khi một tệp nhất định được chọn để phân phối.

Nếu bạn đã thực hiện một truy vấn cơ sở dữ liệu để xác định tên tệp của mình, bạn rất có thể thấy rằng tốt hơn hết là giữ tệp ngay trong bản ghi db, bạn có thể tìm thấy kết quả tốt nhất từ ​​việc điều chỉnh một số cài đặt phân trang trong cơ sở dữ liệu của mình lựa chọn và sau đó lưu trữ các tệp trong db (ví dụ: các trang lớn hơn để giải thích cho tất cả các bản ghi blob) hoặc bạn có thể thấy rằng bạn vẫn tốt hơn khi sử dụng hệ thống tệp.

Tùy chọn cơ sở dữ liệu có cơ hội tốt hơn một chút vì với một triệu bản ghi, có thể mỗi tệp không có khả năng được truy vấn như nhau. Nếu bạn đang ở trong tình huống một tệp có thể được truy vấn nhiều lần liên tiếp hoặc gần như liên tiếp, cơ sở dữ liệu có thể hoạt động như một bộ đệm thực tế cho các tệp được truy xuất gần đây, trong trường hợp đó bạn sẽ thường có kết quả tệp của mình đã được tải vào bộ nhớ. Bạn có thể cần phải điều chỉnh cẩn thận các phần bên trong của công cụ cơ sở dữ liệu của mình để có được hành vi bạn muốn.

Nhưng điều chính yếu để loại bỏ câu trả lời của tôi là bạn không thực sự biết cái gì sẽ hoạt động tốt nhất cho đến khi bạn thử nó với một số dữ liệu thử nghiệm đại diện và đo lường kết quả.


1

Với các hệ thống tập tin hiện đại, nó không phải là vấn đề. Tôi đã thử nghiệm XFS với 1 tỷ tệp trong cùng thư mục và tôi khá chắc chắn rằng ext4 cũng sẽ hoạt động tốt (miễn là bản thân hệ thống tệp không quá lớn). Có đủ bộ nhớ để lưu các mục trong thư mục; bộ nhớ cache bộ xử lý lớn hơn cũng sẽ giúp rất nhiều.


2
Các hệ thống tệp EXT không đối phó tốt với số lượng tệp cao trong cùng một thư mục; đặc biệt là không có cài đặt thư mục_index mặc định. Không kiểm tra XFS với số lượng tệp cao như vậy trong cùng một thư mục nhưng tôi khá chắc chắn EXT sẽ không hoạt động với bất cứ thứ gì từ xa gần 1 tỷ trong cùng một thư mục.
Hrvoje Špoljar

1
Tôi nghe nói reiserfs là tốt cho các tập tin nhỏ, nhưng sau đó tôi cũng nghe nói anh chàng duy trì phần mềm đang ở trong tù (!) Vì vậy tương lai gần của reiserfs là không chắc chắn. Cá nhân tôi muốn đi EXT4 và XFS là lựa chọn thứ hai. Không phải XFS tốt nhất cho các tệp lớn?
vào

Trước đây, nhưng nếu bạn đang chạy kernel mới (3.0 trở lên) thì nó cũng hoạt động tốt đối với các tệp nhỏ.
wazoox
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.