Lưu trữ một triệu hình ảnh trong hệ thống tập tin

Tôi có một dự án sẽ tạo ra một số lượng lớn hình ảnh. Khoảng 1.000.000 để bắt đầu. Chúng không phải là hình ảnh lớn nên tôi sẽ lưu trữ tất cả trên một máy khi bắt đầu.

Làm thế nào để bạn đề nghị lưu trữ những hình ảnh này một cách hiệu quả? (Hệ thống tệp NTFS hiện tại)

Tôi đang xem xét sơ đồ đặt tên ... để bắt đầu, tất cả các hình ảnh sẽ có tên tăng dần từ 1 trở lên. Tôi hy vọng điều này sẽ giúp tôi sắp xếp chúng sau này nếu cần và ném chúng vào các thư mục khác nhau.

những gì sẽ là một kế hoạch đặt tên tốt hơn:

a / b / c / 0 ... z / z / z / 999

hoặc là

a / b / c / 000 ... z / z / z / 999

Bất cứ ý tưởng về điều này?

Tôi khuyên bạn nên sử dụng một hệ thống tệp thông thường thay vì cơ sở dữ liệu. Sử dụng hệ thống tệp dễ dàng hơn cơ sở dữ liệu, bạn có thể sử dụng các công cụ bình thường để truy cập tệp, hệ thống tệp được thiết kế cho loại sử dụng này, vv NTFS nên hoạt động tốt như một hệ thống lưu trữ.

Không lưu trữ đường dẫn thực tế đến cơ sở dữ liệu. Tốt hơn là lưu trữ số thứ tự của hình ảnh vào cơ sở dữ liệu và có chức năng có thể tạo đường dẫn từ số thứ tự. ví dụ:

 File path = generatePathFromSequenceNumber(sequenceNumber);

Sẽ dễ dàng hơn để xử lý nếu bạn cần thay đổi cấu trúc thư mục một số cách. Có thể bạn cần di chuyển hình ảnh đến vị trí khác nhau, có thể bạn hết dung lượng và bạn bắt đầu lưu trữ một số hình ảnh trên đĩa A và một số trên đĩa B, v.v ... Dễ dàng thay đổi một chức năng hơn là thay đổi đường dẫn trong cơ sở dữ liệu .

Tôi sẽ sử dụng loại thuật toán này để tạo cấu trúc thư mục:

1. Đầu tiên, bạn nhập số thứ tự với các số 0 đứng đầu cho đến khi bạn có ít nhất 12 chữ số. Đây là tên cho tập tin của bạn. Bạn có thể muốn thêm một hậu tố:
   • 12345 -> 000000012345.jpg
2. Sau đó chia chuỗi thành 2 hoặc 3 khối ký tự trong đó mỗi khối biểu thị một cấp thư mục. Có một số cấp thư mục cố định (ví dụ 3):
   • 000000012345 -> 000/000/012
3. Lưu trữ tệp vào thư mục được tạo:
   • Do đó, đường dẫn và tên tệp đầy đủ cho tệp có id chuỗi 123là 000/000/012/00000000012345.jpg
   • Đối với tệp có id chuỗi 12345678901234, đường dẫn sẽ là123/456/789/12345678901234.jpg

Một số điều cần xem xét về cấu trúc thư mục và lưu trữ tệp:

• Thuật toán trên cung cấp cho bạn một hệ thống trong đó mỗi thư mục lá có tối đa 1000 tệp (nếu bạn có ít hơn tổng số 1 000 000 000 000 tệp)
• Có thể có giới hạn số lượng tệp và thư mục con mà thư mục có thể chứa, ví dụ hệ thống tệp ext3 trên Linux có giới hạn 31998 thư mục con trên một thư mục.
• Các công cụ bình thường (WinZip, Windows Explorer, dòng lệnh, bash shell, v.v.) có thể không hoạt động tốt nếu bạn có số lượng lớn tệp trên mỗi thư mục (> 1000)
• Bản thân cấu trúc thư mục sẽ chiếm một số dung lượng đĩa, vì vậy bạn sẽ không muốn có quá nhiều thư mục.
• Với cấu trúc trên, bạn luôn có thể tìm đường dẫn chính xác cho tệp hình ảnh bằng cách chỉ nhìn vào tên tệp, nếu bạn tình cờ làm rối cấu trúc thư mục của mình.
• Nếu bạn cần truy cập các tệp từ một số máy, hãy xem xét chia sẻ tệp qua hệ thống tệp mạng.
• Cấu trúc thư mục trên sẽ không hoạt động nếu bạn xóa nhiều tệp. Nó để lại "lỗ hổng" trong cấu trúc thư mục. Nhưng vì bạn không xóa bất kỳ tập tin nào nên nó vẫn ổn.

Tôi sẽ đặt giá trị 2 xu của mình vào một lời khuyên tiêu cực: Đừng đi với cơ sở dữ liệu.

Tôi đã làm việc với cơ sở dữ liệu lưu trữ hình ảnh trong nhiều năm: các tệp lớn (1 meg-> 1 gig), thường được thay đổi, nhiều phiên bản của tệp, được truy cập hợp lý thường xuyên. Các vấn đề cơ sở dữ liệu mà bạn gặp phải với các tệp lớn đang được lưu trữ là vô cùng tẻ nhạt, các vấn đề về văn bản và giao dịch rất khó khăn và bạn gặp phải các vấn đề về khóa có thể gây ra các vụ đắm tàu ​​lớn. Tôi có thực hành nhiều hơn trong viết kịch bản dbcc, và khôi phục lại bảng từ bản sao lưu hơn bất kỳ người bình thường nên bao giờ có.

Hầu hết các hệ thống mới hơn mà tôi đã làm việc đã đẩy lưu trữ tệp vào hệ thống tệp và dựa vào cơ sở dữ liệu không có gì khác hơn là lập chỉ mục. Các hệ thống tệp được thiết kế để xử lý loại lạm dụng đó, chúng dễ dàng mở rộng hơn và bạn hiếm khi mất toàn bộ hệ thống tệp nếu một mục bị hỏng.

Tôi nghĩ rằng hầu hết các trang web phải đối phó với điều này sử dụng một hàm băm nào đó để đảm bảo rằng các tệp được phân phối đều trong các thư mục.

Vì vậy, giả sử bạn có hàm băm của một tệp giống như thế này 515d7eab9c29349e0cde90381ee8f810
Bạn có thể lưu tệp này ở vị trí sau và bạn có thể sử dụng bao nhiêu cấp độ sâu mà bạn cần để giữ số lượng tệp trong mỗi thư mục thấp.
\51\5d\7e\ab\9c\29\349e0cde90381ee8f810.jpg

Tôi đã thấy cách tiếp cận này được thực hiện nhiều lần. Bạn vẫn cần một cơ sở dữ liệu để ánh xạ các tệp băm này thành tên có thể đọc được của con người và bất kỳ siêu dữ liệu nào khác bạn cần lưu trữ. Nhưng cách tiếp cận này có tỷ lệ khá tốt b / c, bạn có thể bắt đầu phân phối không gian địa chỉ băm giữa nhiều máy tính và hoặc nhóm lưu trữ, v.v.

Tốt nhất, bạn nên chạy một số thử nghiệm về thời gian truy cập ngẫu nhiên cho các cấu trúc khác nhau, vì thiết lập ổ cứng cụ thể, bộ nhớ đệm, bộ nhớ khả dụng, v.v. có thể thay đổi các kết quả này.

Giả sử bạn có quyền kiểm soát tên tệp, tôi sẽ phân vùng chúng ở mức 1000 giây cho mỗi thư mục. Bạn càng thêm nhiều cấp độ thư mục, bạn càng đốt được nhiều nút, do đó, có một lực đẩy ở đây.

Ví dụ,

/ root / [0-99] / [0-99] / tên tệp

Lưu ý, http://technet.microsoft.com/en-us/l Library / cc781134 (WS.10) .aspx có nhiều chi tiết hơn về thiết lập NTFS. Cụ thể, "Nếu bạn sử dụng số lượng lớn tệp trong thư mục NTFS (300.000 trở lên), hãy tắt chức năng tạo tên tệp ngắn để có hiệu suất tốt hơn và đặc biệt là nếu sáu ký tự đầu tiên của tên tệp dài tương tự nhau."

Bạn cũng nên xem xét việc vô hiệu hóa các tính năng hệ thống tập tin mà bạn không cần (ví dụ: thời gian truy cập lần cuối). http://www.pctools.com/guides/regology/detail/50/

Dù bạn làm gì, đừng lưu trữ tất cả chúng trong một thư mục.

Tùy thuộc vào việc phân phối tên của các hình ảnh này, bạn có thể tạo cấu trúc thư mục nơi bạn có các thư mục cấp cao nhất của chữ cái trong đó bạn sẽ có một bộ thư mục con khác cho chữ cái thứ 2 của hình ảnh, v.v.

Vì thế:

Thư mục img\a\b\c\d\e\f\g\sẽ chứa các hình ảnh bắt đầu bằng 'abcdefg', v.v.

Bạn có thể giới thiệu độ sâu thích hợp của riêng bạn cần thiết.

Điều tuyệt vời về giải pháp này là cấu trúc thư mục hoạt động hiệu quả như một hashtable / dictionary. Cho một tên tệp hình ảnh, bạn sẽ biết thư mục của nó và được cung cấp một thư mục, bạn sẽ biết một tập hợp con các hình ảnh ở đó.

Tôi sẽ lưu trữ những thứ này trên hệ thống tập tin nhưng nó phụ thuộc vào số lượng tập tin sẽ tăng nhanh như thế nào. Là những tập tin được lưu trữ trên web? Có bao nhiêu người dùng sẽ truy cập các tập tin này? Đây là những câu hỏi cần được trả lời trước khi tôi có thể đưa ra cho bạn một đề xuất tốt hơn. Tôi cũng sẽ xem Haystack từ Facebook, họ có một giải pháp rất tốt để lưu trữ và phục vụ hình ảnh.

Ngoài ra nếu bạn chọn hệ thống tệp, bạn sẽ cần phân vùng các tệp này với các thư mục. Tôi đã xem xét vấn đề này và đề xuất một giải pháp nhưng nó không phải là một giải pháp hoàn hảo. Tôi đang phân vùng theo bảng băm và người dùng bạn có thể đọc thêm trên blog của tôi .

Chúng tôi có một hệ thống cửa hàng ảnh với 4 triệu hình ảnh. Chúng tôi chỉ sử dụng cơ sở dữ liệu cho dữ liệu meta và tất cả hình ảnh được lưu trữ trên hệ thống tệp bằng hệ thống đặt tên đảo ngược, trong đó tên thư mục được tạo từ chữ số cuối của tệp, cuối cùng, v.v. ví dụ: 000001234.jpg được lưu trữ trong cấu trúc thư mục như 4 \ 3 \ 2 \ 1 \ 000001234.jpg.

Lược đồ này hoạt động rất tốt với chỉ mục nhận dạng trong cơ sở dữ liệu, bởi vì nó lấp đầy toàn bộ cấu trúc thư mục.

Điểm nhanh, bạn không cần lưu trữ đường dẫn tệp trong DB của bạn. Bạn chỉ có thể lưu trữ một giá trị số, nếu các tệp của bạn được đặt tên theo cách bạn mô tả. Sau đó, sử dụng một trong các lược đồ lưu trữ được xác định rõ đã được thảo luận, bạn có thể lấy chỉ mục dưới dạng số và rất nhanh tìm thấy tệp bằng cách duyệt qua cấu trúc thư mục.

MS SQL 2008 mới có một tính năng mới để xử lý các trường hợp như vậy, nó được gọi là FILESTREAM. Hãy xem:

Tổng quan về Microsoft TechNet FILESTREAM

Hình ảnh của bạn sẽ cần phải được đặt tên duy nhất? Quá trình tạo ra những hình ảnh này có thể tạo cùng một tên tệp nhiều lần không? Khó có thể nói mà không biết thiết bị nào đang tạo tên tệp nhưng nói rằng thiết bị đó là 'thiết lập lại' và khi khởi động lại, nó bắt đầu đặt tên cho hình ảnh như lần trước là 'đặt lại' - nếu đó là một vấn đề đáng lo ngại ..

Ngoài ra, bạn nói rằng bạn sẽ đạt được 1 triệu hình ảnh trong một tháng. Sau đó thì sao? Làm thế nào nhanh chóng những hình ảnh này sẽ tiếp tục lấp đầy hệ thống tập tin? Họ sẽ đứng đầu tại một số điểm và san bằng khoảng 1 triệu TOTAL hình ảnh hay nó sẽ tiếp tục phát triển và tăng trưởng, từng tháng?

Tôi yêu cầu bởi vì bạn có thể bắt đầu thiết kế hệ thống tệp của mình theo tháng, sau đó bằng hình ảnh. Tôi có thể có xu hướng đề nghị bạn lưu trữ hình ảnh trong cấu trúc thư mục như vậy:

imgs\yyyy\mm\filename.ext

where: yyyy = 4 digit year
         mm = 2 digit month

example:  D:\imgs\2009\12\aaa0001.jpg
          D:\imgs\2009\12\aaa0002.jpg
          D:\imgs\2009\12\aaa0003.jpg
          D:\imgs\2009\12\aaa0004.jpg
                   |
          D:\imgs\2009\12\zzz9982.jpg
          D:\imgs\2010\01\aaa0001.jpg (this is why I ask about uniqueness)
          D:\imgs\2010\01\aab0001.jpg

Tháng, năm, thậm chí ngày là tốt cho hình ảnh loại bảo mật. Không chắc đây có phải là những gì bạn đang làm hay không nhưng tôi đã làm điều đó với một camera an ninh gia đình đã chụp một bức ảnh cứ sau 10 giây ... Bằng cách này, ứng dụng của bạn có thể đi sâu vào thời gian cụ thể hoặc thậm chí là một phạm vi mà bạn có thể nghĩ rằng hình ảnh được tạo ra . Hoặc, thay vì năm, tháng - có một số "ý nghĩa" khác có thể được bắt nguồn từ chính tệp hình ảnh không? Một số mô tả khác, ngoài ví dụ ngày tôi đã đưa ra?

Tôi sẽ không lưu trữ dữ liệu nhị phân trong DB. Không bao giờ có hiệu suất tốt / may mắn với điều đó. Không thể tưởng tượng nó hoạt động tốt với 1 triệu hình ảnh. Tôi sẽ lưu tên tệp và đó là nó. Nếu tất cả chúng sẽ là JPG thì thậm chí không lưu trữ phần mở rộng. Tôi sẽ tạo một bảng điều khiển lưu trữ một con trỏ đến máy chủ, ổ đĩa, đường dẫn, v.v ... Bằng cách này bạn có thể di chuyển những hình ảnh đó sang một hộp khác và vẫn xác định vị trí của chúng. Bạn có cần phải từ khóa thẻ hình ảnh của bạn? Nếu vậy thì bạn sẽ muốn xây dựng các bảng thích hợp cho phép loại gắn thẻ đó.

Bạn / những người khác có thể đã giải quyết những ý tưởng này trong khi tôi đang trả lời .. Hy vọng điều này sẽ giúp ..

Tôi đang tham gia vào một dự án lưu trữ 8.4 triệu hình ảnh trong suốt một năm để ghi lại tình trạng của các thiết bị khác nhau. Nhiều hình ảnh gần đây được truy cập thường xuyên hơn và những hình ảnh cũ hơn hiếm khi được tìm kiếm trừ khi một điều kiện được phát hiện khiến ai đó đào sâu vào kho lưu trữ.

Giải pháp của tôi, dựa trên cách sử dụng này, là tăng dần các hình ảnh thành các tệp nén. Hình ảnh là JPG, mỗi tệp khoảng 20kB và không nén nhiều, vì vậy sơ đồ nén ZIP là không có. Điều này được thực hiện chỉ để ghép chúng vào một mục nhập hệ thống tập tin, giúp ích rất nhiều cho NTFS về tốc độ khi chuyển chúng từ ổ đĩa sang ổ đĩa hoặc xem qua danh sách các tệp.

Hình ảnh cũ hơn một ngày được kết hợp thành một zip "hàng ngày"; zips cũ hơn một tháng được kết hợp vào zip "hàng tháng" tương ứng của họ; và cuối cùng bất cứ điều gì trong một năm không còn cần thiết và do đó bị xóa.

Hệ thống này hoạt động tốt vì người dùng có thể duyệt các tệp (thông qua hệ điều hành hoặc một số ứng dụng khách) và mọi thứ được đặt tên dựa trên tên thiết bị và dấu thời gian. Nói chung, người dùng biết hai thông tin này và có thể nhanh chóng định vị bất kỳ một trong số hàng triệu hình ảnh.

Tôi hiểu điều này có lẽ không liên quan đến chi tiết cụ thể của bạn, nhưng tôi nghĩ tôi sẽ chia sẻ.

Có lẽ một lược đồ đặt tên dựa trên ngày tạo - bao gồm tất cả thông tin trong tên tệp hoặc (tốt hơn để duyệt sau) chia tách nó trong các thư mục. Tôi có thể nghĩ về những điều sau đây, tùy thuộc vào tần suất bạn tạo hình ảnh:

• Một số hình ảnh được tạo ra mỗi ngày: Year/Month/Day/Hour_Minute_Second.png
• Một vài tháng: Year/Month/Day_Hour_Minute_Second.png

v.v ... Bạn nhận được điểm của tôi ... =)

Tôi sẽ có xu hướng tạo cấu trúc thư mục dựa trên ngày, ví dụ \ năm \ tháng \ ngày và sử dụng dấu thời gian cho tên tệp. Nếu cần thiết, dấu thời gian có thể có một thành phần bộ đếm bổ sung nếu hình ảnh được tạo nhanh đến mức có thể có nhiều hơn một trong một phần nghìn giây. Bằng cách sử dụng một chuỗi có ý nghĩa nhất đến ít quan trọng nhất để sắp xếp đặt tên, việc tìm kiếm và bảo trì rất dễ dàng. ví dụ: hhmmssmm [seq] .jpg

Bạn đang xem xét khắc phục thảm họa?

Một số giải pháp được đề xuất ở đây kết thúc việc xáo trộn tên tệp (như vậy nếu tệp vật lý bị di chuyển, bạn sẽ mất dấu vết của tệp thực sự là gì). Tôi khuyên bạn nên duy trì một tên tệp vật lý duy nhất để nếu danh sách chính các vị trí tệp của bạn bị hỏng, bạn có thể tạo lại nó bằng một vỏ nhỏ, er, powershell, script;)

Từ những gì tôi đọc ở đây, có vẻ như tất cả các tệp này sẽ được lưu trữ trên một hệ thống tệp. Xem xét việc lưu trữ chúng trên nhiều hệ thống tệp trên nhiều máy. Nếu bạn có tài nguyên, hãy xác định hệ thống lưu trữ từng tệp trên hai máy khác nhau trong trường hợp bạn mất nguồn điện và việc thay thế là hết 2 ngày.

Xem xét những loại thủ tục bạn cần tạo để di chuyển tệp giữa các máy hoặc hệ thống tệp. Khả năng thực hiện điều này với hệ thống của bạn là trực tuyến và trực tuyến có thể giúp bạn giảm đau đầu đáng kể.

Bạn có thể xem xét sử dụng GUID làm tên tệp vật lý thay vì số tăng trong trường hợp bộ đếm số tăng của bạn (cột nhận dạng cơ sở dữ liệu?) Bị rối tung.

Nếu thích hợp, hãy cân nhắc sử dụng CDN như Amazon S3.

Mặc dù tôi chưa phục vụ ảnh ở quy mô đó, trước đây tôi đã viết một ứng dụng thư viện nhỏ để phục vụ ~ 25k ảnh trên máy 400 MHz w. 512 MB RAM hoặc hơn. Một số kinh nghiệm;

• Tránh một cơ sở dữ liệu quan hệ bằng mọi giá; trong khi cơ sở dữ liệu, không nghi ngờ gì, thông minh về việc xử lý dữ liệu, chúng không được thiết kế để sử dụng như vậy (chúng tôi có cơ sở dữ liệu khóa-giá trị phân cấp chuyên biệt cho hệ thống tệp được gọi là ). Mặc dù tôi không có gì hơn là linh cảm, tôi muốn rằng bộ đệm DB sẽ tắt ngoài cửa sổ, nếu bạn ném những đốm sáng thực sự lớn vào nó. Mặc dù phần cứng khả dụng của tôi chỉ ở mức nhỏ, nhưng hoàn toàn không chạm vào DB khi tra cứu hình ảnh đã cho các lệnh có tốc độ tốt hơn.

• Nghiên cứu cách hệ thống tập tin ứng xử; trên ext3 (hoặc là ext2 tại thời điểm đó - không thể nhớ), giới hạn khả năng tra cứu hiệu quả các thư mục con và tệp nằm trong khoảng 256; vì vậy chỉ có nhiều tệp và thư mục trong bất kỳ thư mục nào. Một lần nữa, tăng tốc đáng chú ý. Mặc dù tôi không biết về NTFS, nhưng những thứ như XFS (sử dụng cây B, theo như tôi nhớ) thì cực kỳ nhanh, đơn giản vì chúng có thể thực hiện tra cứu cực nhanh.

• Phân phối dữ liệu đồng đều; Khi tôi thử nghiệm ở trên, tôi đã cố gắng phân phối dữ liệu đều trên tất cả các thư mục (Tôi đã thực hiện MD5 của URL và sử dụng dữ liệu đó cho các thư mục; /1a/2b/1a2b...f.jpg). Bằng cách đó, sẽ mất nhiều thời gian hơn để đạt được bất kỳ giới hạn hiệu suất nào (và bộ đệm của hệ thống tệp không có giá trị tại các bộ dữ liệu lớn như vậy). (thông thường, bạn có thể muốn xem giới hạn sớm ở đâu; sau đó bạn muốn ném mọi thứ vào thư mục có sẵn đầu tiên.

Có thể bị trễ trò chơi về điều này. Nhưng một giải pháp (nếu phù hợp với trường hợp sử dụng của bạn) có thể là băm tên tệp. Đó là một cách để tạo một đường dẫn tệp có thể tái tạo dễ dàng bằng cách sử dụng tên của tệp trong khi cũng tạo cấu trúc thư mục được phân phối tốt. Ví dụ: bạn có thể sử dụng các byte của mã băm của tên tệp làm đường dẫn:

String fileName = "cat.gif";
int hash = fileName.hashCode();
int mask = 255;
int firstDir = hash & mask;
int secondDir = (hash >> 8) & mask;

Điều này sẽ dẫn đến đường dẫn:

/172/029/cat.gif

Sau đó, bạn có thể tìm thấy cat.giftrong cấu trúc thư mục bằng cách tái tạo thuật toán.

Sử dụng HEX làm tên thư mục sẽ dễ dàng như chuyển đổi các intgiá trị:

String path = new StringBuilder(File.separator)
        .append(String.format("%02x", firstDir))
        .append(File.separator)
        .append(String.format("%02x", secondDir)
        .toString();

Kết quả là:

/AC/1D/cat.gif

Tôi đã viết một bài báo về điều này một vài năm trước và gần đây đã chuyển nó sang Trung bình. Nó có thêm một vài chi tiết và một số mã mẫu: Băm tên tệp: Tạo cấu trúc thư mục băm . Hi vọng điêu nay co ich!

Nếu bạn đang ở trên windows thì thế nào về một filessytem exFat

http://msdn.microsoft.com/en-us/l Library / aa914353.aspx

nó được thiết kế để lưu trữ các tập tin đa phương tiện và hiện có sẵn.

Nếu TẤT CẢ chúng không được yêu cầu ngay lập tức và bạn có thể tạo chúng nhanh chóng và đây là những hình ảnh nhỏ, tại sao không triển khai bộ nhớ LRU hoặc bộ đệm đĩa phía trên trình tạo hình ảnh của bạn?

Điều này có thể cứu bạn khỏi bộ lưu trữ và giữ những hình ảnh nóng được phục vụ từ mem?

Tôi vừa chạy thử nghiệm trên zfs vì tôi yêu zfs và tôi có phân vùng 500gig mà tôi đã nén. Tôi đã viết một tập lệnh tạo ra 50-100k tệp và đặt chúng vào các thư mục lồng nhau 1/2/3/4/5/6/7/8 (sâu 5-8 cấp) và để nó chạy trong 1 tuần. (nó không phải là một tập lệnh tuyệt vời.) Nó chứa đầy đĩa và cuối cùng có khoảng 25 triệu tệp. Truy cập vào bất kỳ một tập tin với một đường dẫn đã biết là ngay lập tức. Liệt kê bất kỳ thư mục với một đường dẫn đã biết là ngay lập tức.

Việc đếm số lượng danh sách các tập tin tuy nhiên (thông qua tìm) mất 68 giờ.

Tôi cũng đã chạy thử nghiệm đặt rất nhiều tệp trong một thư mục. Tôi đã nhận được khoảng 3,7 triệu tệp trong một thư mục trước khi dừng. Liệt kê thư mục để có được một số lượng mất khoảng 5 phút. Xóa tất cả các tệp trong thư mục đó mất 20 giờ. Nhưng tra cứu và truy cập vào bất kỳ tập tin là ngay lập tức.

Tôi thấy khác đề cập đến một cơ sở dữ liệu, nhưng không thấy đề cập đến điều đó trong bài viết của bạn. Trong mọi trường hợp, ý kiến ​​của tôi về điểm đặc biệt này là: hoặc dính vào cơ sở dữ liệu hoặc hệ thống tệp. Nếu bạn phải trộn cả hai, hãy cẩn thận về nó. Mọi thứ trở nên phức tạp hơn. Nhưng bạn có thể phải. Lưu trữ một triệu bức ảnh trong cơ sở dữ liệu không phải là ý tưởng tốt nhất.

Bạn có thể quan tâm theo thông số kỹ thuật sau, hầu hết các máy ảnh kỹ thuật số tuân theo nó để quản lý lưu trữ tệp: https://en.wikipedia.org/wiki/Camera_Image_File_Format

Về cơ bản, một thư mục được tạo, chẳng hạn như 000OLYMPUSvà ảnh được thêm vào thư mục đó (ví dụ DSC0000.RAW). Khi bộ đếm tên tệp đạt đến DSC9999.RAWmột thư mục mới được tạo ( 001OLYMPUS) và hình ảnh được thêm lại, đặt lại bộ đếm, có thể có tiền tố khác (ví dụ P_0000.RAW:).

Ngoài ra, bạn cũng có thể tạo các thư mục dựa trên các phần của tên tệp (đã được đề cập nhiều lần). Ví dụ: nếu ảnh của bạn được đặt tên IMG_A83743.JPG, hãy lưu trữ tại IMG_\A8\3\IMG_A83743.JPG. Nó phức tạp hơn để thực hiện nhưng sẽ làm cho các tập tin của bạn dễ dàng tìm thấy hơn.

Tùy thuộc vào hệ thống tập tin (điều này sẽ yêu cầu một số nghiên cứu), bạn có thể chỉ cần đổ tất cả các hình ảnh trong một thư mục, nhưng, theo kinh nghiệm của tôi, điều này thường sẽ gây ra vấn đề về hiệu suất.

Bạn có thể muốn xem ZFS (hệ thống tệp, trình quản lý âm lượng từ Sun) Trân trọng

Một cách sạch để tạo đường dẫn từ một số lượng lớn là dễ dàng chuyển đổi nó thành hex sau đó tách nó ra!

ví dụ 1099496034834> 0xFFFF1212>FF/FF/12/12

public string GeneratePath(long val)
{  
    string hex = val.ToString("X");
    hex=hex.PadLeft(10, '0');
    string path="";
    for(int i=0; i<hex.Length; i+=2 )
    {
        path += hex.Substring(i,2);
        if(i+2<hex.Length)
            path+="/";
    }
    return path;
}

Lưu trữ và tải:

public long Store(Stream doc)
{
   var newId = getNewId();
   var fullpath = GeneratePath(newId)
   // store into fullpath 
   return newId;
}

public Stream Load(long id)
{
   var fullpath = GeneratePath(newId)
   var stream = ... 
   return stream;
}

Mã nguồn đầy đủ: https://github.com/acrobit/AcroFS

Thật không may, hệ thống tệp rất tệ (hiệu suất với nhiều tệp trên mỗi thư mục hoặc cây thư mục sâu, kiểm tra thời gian khởi động lại, độ tin cậy) trong việc quản lý nhiều tệp nhỏ, vì vậy giải pháp trên liên quan đến tệp ZIP là tốt nhất nếu bạn muốn sử dụng hệ thống tệp.

Sử dụng một trình quản lý cơ sở dữ liệu cho đến nay là lựa chọn tốt nhất; một ví dụ đơn giản như BDB hoặc GDBM chẳng hạn; thậm chí một DBMS tương đối như MySQL sẽ tốt hơn. Chỉ những người lười biếng không hiểu hệ thống tệp và cơ sở dữ liệu (ví dụ: những người loại bỏ giao dịch) có xu hướng sử dụng hệ thống tệp làm cơ sở dữ liệu (hoặc hiếm khi hơn, ngược lại).

Làm thế nào về một cơ sở dữ liệu với một bảng chứa ID và BLOB để lưu trữ hình ảnh? Sau đó, bạn có thể thêm (các) bảng mới bất cứ khi nào bạn muốn liên kết nhiều yếu tố dữ liệu hơn với ảnh.

Nếu bạn đang mong muốn mở rộng quy mô, tại sao không mở rộng ngay bây giờ? Bạn sẽ tiết kiệm thời gian cả IMO bây giờ và sau này. Thực hiện lớp cơ sở dữ liệu một lần, khá dễ dàng để bắt đầu. Hoặc thực hiện một số thứ với các thư mục và tên tệp và blah blah blah, và sau đó chuyển sang một thứ khác khi bạn bắt đầu thổi lên MAX_PATH.