2009-10-23 13 views
13

Nếu tôi có một trang web nơi người dùng có thể tải lên bao nhiêu hình ảnh tùy ý, cách tốt nhất để thiết lập lưu trữ tệp (đồng thời, tất cả tải lên sẽ nhận được dấu thời gian ngẫu nhiên duy nhất) là gì?Việc lưu trữ nhiều hình ảnh trong một thư mục có làm chậm quá trình truy xuất hình ảnh không?

site root 
--username 
----image1.jpg 
----image2.jpg 
----image3.jpg 
--anotheruser 
----image1.jpg 
----image2.jpg 
----image3.jpg 
... 

hoặc

siteroot 
--uploads 
----image1.jpg 
----image2.jpg 
----image3.jpg 
----image4.jpg 
----image6.jpg 
... 
----image50000.jpg 

Tôi nghĩ rằng phương pháp đầu tiên là có tổ chức hơn. Nhưng tôi nghĩ phương pháp thứ hai là tiêu chuẩn (giữ tất cả video tải lên trong cùng một thư mục), nhưng tôi tự hỏi nếu nó sẽ chậm hơn khi truy xuất hình ảnh nếu có hàng nghìn hình ảnh trong cùng một thư mục

--- edit - -

Cảm ơn câu trả lời tuyệt vời cho đến thời điểm này. Ngoài ra, tôi sẽ tạo hình thu nhỏ, vì vậy tôi cũng sẽ phải chèn thư mục đó vào một nơi nào đó ... hoặc, tạo quy ước đặt tên như thumb_whatever.jpg.

rất nhiều cách khác nhau để thực hiện việc này. Có không gian đĩa sẽ là một vấn đề. nhưng hiện tại tôi quan tâm đến thời gian truy xuất. Khi tôi phải xuất một hình ảnh cho trình duyệt, nếu hình ảnh đó nằm trong một thư mục với 10.000 hình ảnh khác, tôi lo lắng về việc làm thế nào có thể nhận được chậm.

Trả lời

19

Số lượng tệp trong thư mục sẽ không có hiệu lực vào thời gian cần thiết để đọc dữ liệu của tệp - nhưng nó có thể ảnh hưởng đến lượng thời gian cần thiết để tìm tệp trước khi bạn có thể bắt đầu đọc.

Điểm ngắt chính xác nơi các vấn đề chính khởi động sẽ thay đổi từ loại hệ thống tệp sang loại hệ thống tệp, nhưng nói chung, nếu bạn đang nói về vài trăm tệp, bạn không cần phải lo lắng về nó. Nếu bạn đang nói về một vài nghìn, nó đáng để suy nghĩ và có thể làm một chút điểm chuẩn để xem cách hệ thống tập tin và phần cứng của bạn xử lý nó như thế nào. Nếu bạn đang nói về hàng chục ngàn tập tin, thì bạn thực sự cần phải bắt đầu phá vỡ mọi thứ. (Tôi đã từng có một máy chủ in Linux/e2fs nơi CUPS không xóa các tệp điều khiển công việc của nó sau khi in xong và nó đã nhận được khoảng 100.000 tệp trong một thư mục. Chỉ cần danh sách thư mục mất hơn nửa giờ trước khi nó bắt đầu hiển thị bất kỳ tên tệp nào.)

Tách chúng theo tên người dùng có thể không phải là lựa chọn tốt nhất, vì bạn có thể có rất nhiều người dùng tải lên rất ít hình ảnh và có lẽ một vài người tải lên hàng trăm hoặc hàng nghìn hình ảnh tạo các vấn đề về thời gian truy cập trong các thư mục lưu trữ của người dùng đó. Vấn đề lớn hơn trong kịch bản đó là bạn có thể kết thúc (giả sử một trang web thành công) với hàng ngàn hoặc hàng chục nghìn người dùng và một số lượng lớn các thư mục con cũng tệ như một số lượng lớn tệp để làm chậm quyền truy cập vào dữ liệu.

Vì bạn sẽ có dấu thời gian trên chúng, điều tôi có thể làm là đặt chúng vào các thư mục con dựa trên ba số cuối của dấu thời gian cuối cùng ba dấu thời gian. Điều đó sẽ phân phối các tập tin tương đối đồng đều trên 1000 thư mục con và nên giữ số lượng tệp trong mỗi thư mục một cách hợp lý nhỏ. (Sử dụng ba chữ số đầu tiên sẽ làm cho một thư mục được điền trước khi chuyển sang thư mục kế tiếp thay vì phân phối chúng đồng đều.) Nếu bạn vẫn kết thúc với quá nhiều tệp trong mỗi thư mục con (điều này có nghĩa là bạn đang xử lý một số hàng triệu hình ảnh được tải lên), bạn có thể thêm cấp thứ hai cho ba chữ số trước đó, vì vậy, tải lên-1234567890.jpg sẽ kết thúc tại /567/890/upload-1234567890.jpg.

+2

Kỹ thuật rất thú vị – Yarin

0

Tôi nghĩ rằng các thư mục con trong thư mục tải lên sẽ là tốt nhất.

site root 
--uploads 
----username 
------image1.jpg 
------image2.jpg 
------image3.jpg 
----anotheruser 
------image1.jpg 
------image2.jpg 
------image3.jpg 
... 

Tùy thuộc vào hệ điều hành chủ, có quá nhiều tệp trong một thư mục có thể gây ra một số vấn đề về tính tương thích và nhức đầu. Ngoài ra, tùy thuộc vào cách bạn đang nhận được danh sách hình ảnh, nó có thể gây ra vấn đề hiệu suất.

Ngoài ra, tùy chọn 2 sẽ là một mớ hỗn độn. :)

5

Câu trả lời cho điều đó là "có thể". Có thể khôi phục tập tin có thể tốt, nhưng nếu bạn cần thực hiện bất kỳ bảo trì nào trên thư mục, nó sẽ là một nhức đầu rất lớn khi các quá trình cố gắng liệt kê danh sách thư mục.

Điều gì sẽ cải thiện tình hình sẽ là một số thư mục con trong thư mục hình ảnh (hoặc hai cấp độ, tùy thuộc vào có bao nhiêu hình ảnh mà bạn đang nhìn vào lưu trữ), do đó bạn có một hệ thống phân cấp như thế này:

siteroot 
-- uploads 
---- a 
---- b 
---- c 
    : 
---- z 

... và sau đó lưu trữ tệp dựa trên chữ cái đầu tiên của chúng (vì vậy tất cả hình ảnh có tên bắt đầu là 'a' đi vào thư mục 'a'). Bạn có thể có này như một hậu tố hai hoặc ba chữ cái (aa, ab, ac, quảng cáo ..., ba, bb, bc ..., zx, zy, zz) và có thể có một hệ thống phân cấp theo đó cũng như vậy bạn chia tệp trên một số thư mục phụ thuộc vào bốn ký tự đầu tiên của tên.

Nếu tệp sau đó được gán một tên alpha-số ngẫu nhiên thì điều này sẽ đảm bảo các tệp được trải đều trên tất cả các thư mục (cho kích thước mẫu đủ lớn).

Bạn có thể muốn xem xét kết hợp tùy chọn của mình (1) và tách hình ảnh trên một cấu trúc phân cấp như tôi đã mô tả ở trên. Điều đó sẽ đảm bảo rằng nếu một người dùng duy nhất tải lên nhiều tệp thì bạn sẽ được bảo vệ. Tương tự, nếu bạn đang xem nhiều thư mục người dùng, nguyên tắc tương tự cũng được áp dụng để đảm bảo bạn không có 1.000.000 thư mục người dùng trong một người cha/mẹ.

+0

tất cả đều đẹp ... cho đến khi bạn hết dung lượng đĩa. – Toad

+3

@reinier - bạn sẽ gặp vấn đề về diskspace bất kể bạn sử dụng chiến lược nào. Vào cuối ngày, nó là phần mềm để xử lý một thất bại chính xác. Nếu bạn đang nghĩ đến số lượng inode, thì hai thư mục của các thư mục là 676 nút (giả sử chỉ có A-Z). OP có liên quan đến hàng chục nghìn tệp.Thêm một vài thư mục sẽ không ảnh hưởng đến điều đó. –

+0

chris: cũng không phải nếu bạn sử dụng một db nơi thêm không gian thêm là dễ dàng như cấu hình một tập tin ini. Với các lược đồ thư mục như bạn đề xuất, việc thêm các đĩa cứng vật lý sẽ dẫn đến thay đổi lược đồ đặt tên và do đó bạn phải viết một tập lệnh chuyển tất cả các tệp và thư mục sang lược đồ mới, có khả năng chạy trong ngày – Toad

2

thử sử dụng mongodb ...nó là một db keyvalue cũng cho phép lưu trữ dữ liệu nhị phân. Nó rất nhanh và hiệu quả và hỗ trợ sharding (đặt dữ liệu qua nhiều máy) ra khỏi hộp

bạn thực sự không muốn có thư mục và thư mục chứa đầy đủ các tệp. Quản lý các thư mục này sẽ mất vĩnh viễn và việc thay đổi lược đồ đặt tên/chia nhỏ sau đó là một cơn ác mộng. Hơn nữa, nếu bạn chạy ra khỏi diskspace bạn có một vấn đề. Ngoài ra để cân bằng tải, có một đĩa cứng đầy đủ với các tệp không hiệu quả

1

Nó phụ thuộc vào hệ thống tệp. Ví dụ, FAT16 có xu hướng khá chậm nếu bạn có nhiều hơn 512 tệp trong một thư mục. FAT32 và NTFS không có cùng giới hạn nhưng cũng chạy chậm hơn nhiều nếu bạn có số lượng tệp cực lớn. Ngay cả khi bạn đang chạy một trong các hệ thống tệp Linux mạnh mẽ hơn, bạn vẫn có thể phân tích cú pháp các thư mục nhanh hơn nếu chúng nhỏ hơn.

Tôi chắc chắn sẽ đi với # 2 - chia hình ảnh thành các thư mục theo người dùng.

2

Tôi thường sử dụng sơ đồ như thế này: uploads/(# id% 1000) /img_#id.jpg

đâu #ID là OFC. số id (số nguyên) của ảnh được lưu trữ trong cơ sở dữ liệu. Điều đó cung cấp lược đồ đơn giản chỉ dựa trên id của ảnh.