Lưu trữ hình ảnh có kích thước lớn

Question

Tôi có thể sẽ tham gia vào một dự án trong đó một thành phần quan trọng là lưu trữ cho một số lượng lớn tệp (trong trường hợp này là hình ảnh, nhưng nó chỉ hoạt động như một tệp lưu trữ).

Số lượng tệp đến được dự kiến ​​là khoảng 500.000 mỗi tuần (trung bình khoảng 100 Kb mỗi tệp), đạt khoảng 100.000 tệp mỗi ngày và 5 mỗi giây. Tổng số tệp được mong đợi đạt đến hàng chục triệu trước khi đạt đến trạng thái cân bằng khi tệp đang hết hạn vì nhiều lý do khác nhau ở tốc độ đầu vào.

Vì vậy, tôi cần một hệ thống có thể lưu trữ khoảng 5 tệp mỗi giây vào giờ cao điểm, trong khi đọc khoảng 4 và xóa 4 bất kỳ lúc nào.

Ý tưởng ban đầu của tôi là hệ thống tệp NTFS đơn giản với dịch vụ đơn giản để lưu trữ, hết hạn và đọc thực sự là đủ. Tôi có thể tưởng tượng dịch vụ tạo các thư mục con cho mỗi năm, tháng, ngày và giờ để giữ số lượng tệp cho mỗi thư mục ở mức tối thiểu và cho phép hết hạn thủ công trong trường hợp cần thiết.

Một giải pháp NTFS lớn đã được thảo luận here, nhưng tôi vẫn có thể sử dụng một số lời khuyên về những vấn đề mong đợi khi xây dựng một lưu trữ với các thông số đã đề cập, những vấn đề bảo trì mong đợi và lựa chọn thay thế nào. Tốt hơn là tôi muốn tránh một kho lưu trữ phân tán, nếu có thể và thực tế.

chỉnh sửa

Cảm ơn tất cả các ý kiến ​​và đề xuất. Một số thông tin bổ sung về dự án:

Đây không phải là ứng dụng web nơi hình ảnh được cung cấp bởi người dùng cuối. Nếu không tiết lộ quá nhiều, vì đây là trong giai đoạn hợp đồng, nó có nhiều trong danh mục kiểm soát chất lượng. Hãy suy nghĩ nhà máy sản xuất với băng tải và cảm biến. Nó không phải là kiểm soát chất lượng truyền thống vì giá trị của sản phẩm hoàn toàn phụ thuộc vào cơ sở dữ liệu hình ảnh và siêu dữ liệu hoạt động trơn tru.

Các hình ảnh được truy cập 99% bởi một ứng dụng tự động trong lần đầu tiên trong - ra thứ tự đầu tiên, nhưng truy cập ngẫu nhiên bởi một ứng dụng người dùng cũng sẽ xảy ra. Hình ảnh cũ hơn một ngày sẽ chủ yếu phục vụ mục đích lưu trữ, mặc dù mục đích đó cũng rất quan trọng.

Hết hạn hình ảnh theo các quy tắc phức tạp vì nhiều lý do khác nhau, nhưng vào một số ngày, tất cả hình ảnh sẽ bị xóa. Quy tắc xóa theo logic nghiệp vụ phụ thuộc vào siêu dữ liệu và tương tác của người dùng.

Sẽ có thời gian ngừng hoạt động mỗi ngày, nơi có thể thực hiện bảo trì.

Tốt hơn là bộ nhớ tệp sẽ không phải truyền đạt vị trí hình ảnh quay lại máy chủ siêu dữ liệu. Vị trí hình ảnh nên được khấu trừ duy nhất từ ​​siêu dữ liệu, có thể mặc dù một cơ sở dữ liệu bản đồ, nếu một số loại băm hoặc hệ thống phân phối được chọn.

Vì vậy, câu hỏi của tôi là:

• Những công nghệ sẽ làm một công việc mạnh mẽ?
• Công nghệ nào sẽ có chi phí triển khai thấp nhất?
• Công nghệ nào sẽ dễ dàng nhất để duy trì bởi phòng CNTT của khách hàng?
• Có những rủi ro gì đối với một công nghệ nhất định ở quy mô này (5-20 TB dữ liệu, 10-100 triệu tệp)?

Answer 1

Dưới đây là một số suy nghĩ ngẫu nhiên về triển khai và các vấn đề có thể xảy ra dựa trên giả định sau: kích thước hình ảnh trung bình 100kb và trạng thái ổn định là 50M (5GB) hình ảnh. Điều này cũng giả định người dùng sẽ không thể truy cập vào các kho tập tin trực tiếp, và sẽ làm điều đó thông qua phần mềm hoặc một trang web:

1. lưu trữ trung bình: Kích thước của hình ảnh mà bạn cung cấp cho một lượng đến một thay ít ỏi đọc và ghi tốc độ, Tôi nghĩ rằng hầu hết các ổ cứng thông thường sẽ không có vấn đề với thông lượng này. Tuy nhiên, tôi sẽ đặt chúng vào một cấu hình RAID1 để bảo mật dữ liệu. Sao lưu sẽ không xuất hiện quá nhiều vấn đề vì nó chỉ có 5gb dữ liệu.

2. Lưu trữ tệp: Để ngăn các sự cố có tệp tối đa trong một thư mục, tôi sẽ lấy hàm băm (MD5 tối thiểu, đây sẽ là nhanh nhất, nhưng hầu hết khả năng xảy ra va chạm. Và trước khi mọi người kêu gọi MD5 bị hỏng, Điều này là để nhận dạng và không an toàn. Kẻ tấn công có thể tạo hình ảnh cho một cuộc tấn công trước và thay thế tất cả hình ảnh bằng con dê, nhưng chúng tôi sẽ xem xét điều này) và chuyển đổi thành chuỗi thập lục phân. Sau đó, khi nói đến thời gian để lưu trữ các tập tin trong hệ thống tập tin, lấy chuỗi hex trong khối 2 ký tự, và tạo ra một cấu trúc thư mục cho tập tin đó dựa trên đó. Ví dụ. nếu tập tin băm thành abcdef, thư mục gốc sẽ là ab thì dưới thư mục đó có tên là cd, theo đó bạn sẽ lưu hình ảnh có tên là abcdef. Tên thật sẽ được giữ ở một nơi khác (được thảo luận bên dưới).

   Với phương pháp này, nếu bạn bắt đầu nhấn giới hạn hệ thống tệp (hoặc vấn đề hiệu suất) từ quá nhiều tệp trong một thư mục, bạn chỉ có thể lưu trữ phần tạo một cấp thư mục khác. Bạn cũng có thể lưu trữ với siêu dữ liệu bao nhiêu cấp thư mục mà tệp đã được tạo, vì vậy nếu bạn mở rộng sau này, các tệp cũ hơn sẽ không được tìm kiếm trong các thư mục mới hơn, sâu hơn.

   Một lợi ích khác ở đây: Nếu bạn gặp vấn đề về tốc độ truyền hoặc vấn đề về hệ thống tệp nói chung, bạn có thể dễ dàng tách một tập hợp khỏi tệp thành các ổ đĩa khác. Chỉ cần thay đổi phần mềm để giữ các thư mục cấp cao nhất trên các ổ đĩa khác nhau. Vì vậy, nếu bạn muốn chia cửa hàng một nửa, 00-7F trên một ổ đĩa, 80-FF trên một ổ đĩa khác.

   Việc băm nhỏ cũng sẽ lưu trữ một bộ nhớ mẫu đơn, điều này có thể tốt đẹp. Kể từ khi băm của một tập hợp bình thường của các tập tin có xu hướng được ngẫu nhiên, điều này cũng nên net bạn phân phối ngay cả các tập tin trên tất cả các thư mục.

3. Bộ nhớ siêu dữ liệu: Trong khi hàng 50M có vẻ như rất nhiều, hầu hết DBMS được xây dựng để chế giễu tại số lượng bản ghi đó, với đủ RAM, tất nhiên. Sau đây được viết dựa trên SQL Server, nhưng tôi chắc chắn hầu hết trong số này sẽ áp dụng cho những người khác.Tạo một bảng với hàm băm của tệp làm khóa chính, cùng với những thứ như kích thước, định dạng và cấp độ lồng nhau. Sau đó tạo một bảng khác với một khóa nhân tạo (một cột Identity sẽ là tốt cho điều này), và cũng là tên gốc của tệp (varchar (255) hoặc bất kỳ thứ gì), và băm như khóa ngoài trở lại bảng đầu tiên, và ngày được thêm vào, với chỉ mục trên cột tên tệp. Ngoài ra, hãy thêm bất kỳ cột nào khác mà bạn cần tìm ra nếu tệp hết hạn hay không. Điều này sẽ cho phép bạn lưu trữ tên gốc nếu bạn có người cố gắng để đặt cùng một tệp trong các tên khác nhau (nhưng nếu không giống nhau, vì chúng băm giống nhau).

4. Bảo trì: Đây phải là nhiệm vụ được lên lịch. Hãy để Windows lo lắng về thời điểm công việc của bạn chạy, ít hơn cho bạn để gỡ lỗi và nhận sai (nếu bạn bảo trì mỗi tối lúc 2:30 sáng, và bạn ở đâu đó quan sát mùa hè/tiết kiệm ánh sáng ban ngày. trong suốt mùa xuân). Sau đó, dịch vụ này sẽ chạy một truy vấn đối với cơ sở dữ liệu để thiết lập tệp nào hết hạn (dựa trên dữ liệu được lưu trữ cho mỗi tên tệp, vì vậy nó biết khi nào tất cả các tham chiếu trỏ đến tệp được lưu trữ đã hết hạn. ít nhất một hàng trong bảng tên tệp không còn cần thiết nữa). Dịch vụ sau đó sẽ xóa các tệp này.

Tôi nghĩ đó là về nó đối với các bộ phận chính.

EDIT: Cảm nhận của tôi đã trở nên quá dài, di chuyển nó thành một biên tập:

Rất tiếc, sai lầm của tôi, đó là những gì tôi nhận được để làm toán khi tôi mệt mỏi. Trong trường hợp này, nếu bạn muốn tránh sự dư thừa bổ sung của việc thêm các mức RAID (51 hoặc 61 ví dụ như được nhân đôi trên một bộ sọc), băm sẽ cho bạn lợi ích của việc có thể đặt 5 ổ đĩa 1 TB vào máy chủ, và sau đó có các phần mềm lưu trữ tập tin span các ổ đĩa của băm như đã đề cập ở phần cuối của 2. Bạn thậm chí có thể RAID1 các ổ đĩa để tăng cường bảo mật cho việc này.

Sao lưu sẽ phức tạp hơn, mặc dù thời gian tạo/sửa đổi hệ thống tệp vẫn giữ để thực hiện việc này (Bạn có thể chạm vào từng tệp để cập nhật thời gian sửa đổi khi thêm tham chiếu mới vào tệp đó).

Tôi thấy nhược điểm hai lần để theo ngày/giờ cho các thư mục. Đầu tiên, phân phối sẽ không đồng nhất, điều này sẽ khiến một số thư mục đầy đủ hơn các thư mục khác. Hashing sẽ phân phối đồng đều. Đối với spanning, bạn có thể theo dõi không gian trên ổ đĩa khi bạn thêm các tập tin, và bắt đầu tràn sang ổ đĩa tiếp theo khi không gian hết. Tôi tưởng tượng một phần của hết hạn là ngày liên quan, vì vậy bạn sẽ có ổ đĩa cũ bắt đầu trống rỗng như những cái mới hơn điền vào, và bạn sẽ phải tìm ra cách để cân bằng đó.

Cửa hàng siêu dữ liệu không phải nằm trên chính máy chủ. Bạn đã lưu trữ dữ liệu liên quan đến tệp trong cơ sở dữ liệu. Trái với việc chỉ tham chiếu đường dẫn trực tiếp từ hàng mà nó được sử dụng, thay vào đó hãy tham chiếu khóa tên tệp (bảng thứ hai tôi đã đề cập).

Tôi tưởng tượng người dùng sử dụng một số loại web hoặc ứng dụng để giao tiếp với cửa hàng, vì vậy các tính năng để tìm ra nơi tệp sẽ xuất hiện trên máy chủ lưu trữ sẽ tồn tại ở đó và chỉ chia sẻ nguồn gốc của ổ đĩa (hoặc làm một số công cụ ưa thích với nối tiếp NTFS để đặt tất cả các ổ đĩa vào một thư mục con). Nếu bạn đang mong muốn kéo xuống một tệp thông qua một trang web, hãy tạo một trang trên trang web có ID tên tệp, sau đó thực hiện tra cứu trong DB để lấy hàm băm, sau đó nó sẽ băm băm lên bất kỳ cấu hình nào và yêu cầu chia sẻ trên máy chủ, sau đó truyền lại cho khách hàng. Nếu mong đợi một UNC truy cập vào tập tin, có máy chủ chỉ cần xây dựng UNC để thay thế.

Cả hai phương pháp này sẽ làm cho ứng dụng người dùng cuối của bạn ít phụ thuộc vào cấu trúc trên hệ thống tệp và sẽ giúp bạn dễ dàng tinh chỉnh và mở rộng bộ nhớ của mình sau này.

Answer 2

Lưu trữ hình ảnh trong một loạt cơ sở dữ liệu SQLite. Âm thanh điên lúc đầu nhưng nó nghiêm túc là nhanh hơn so với lưu trữ chúng trên hệ thống tập tin trực tiếp, và chiếm ít không gian hơn.

SQLite cực kỳ hiệu quả trong việc lưu trữ dữ liệu nhị phân và lưu trữ tệp trong cơ sở dữ liệu tổng hợp thay vì tệp OS riêng lẻ, tiết kiệm phí khi hình ảnh không vừa với kích thước khối chính xác (điều này rất quan trọng đối với nhiều tệp này). Ngoài ra dữ liệu phân trang trong SQLite có thể cung cấp cho bạn thông lượng tổng thể nhanh hơn bạn sẽ nhận được với các tệp OS đơn giản.

SQLite có giới hạn đồng thời về viết nhưng cũng nằm trong giới hạn bạn đang nói và có thể được giảm thiểu hơn nữa bằng cách sử dụng thông minh của nhiều (hàng trăm) cơ sở dữ liệu SQLite.

Hãy dùng thử, bạn sẽ ngạc nhiên.

Answer 3

Chỉ một vài gợi ý, dựa trên thông tin chung được cung cấp tại đây, không biết chi tiết về những gì ứng dụng của bạn thực sự làm hoặc sẽ thực hiện.

• sử dụng sha1 của tập tin như một tên tập tin (nếu cần thiết, tên tập tin lưu trữ người dùng cung cấp trong DB)

  điều là nếu bạn quan tâm đến dữ liệu, bạn sẽ phải lưu trữ một checksum anyways.
  Nếu bạn sử dụng sha1 (sha256, md5, băm khác) thì sẽ dễ dàng xác thực dữ liệu tệp - đọc tệp, băm cacl, nếu nó khớp với tên thì dữ liệu hợp lệ. Giả sử rằng đây là một ứng dụng web của một số loại, tên tệp dựa trên băm có thể được sử dụng dưới dạng etag khi phân phối dữ liệu. (hãy kiểm tra thư mục .git của bạn để biết ví dụ về điều này). Điều này giả định rằng bạn không thể sử dụng tên tập tin người dùng cung cấp anyways, là người dùng có thể gửi một cái gì đó như "<>? :() txt."

• sử dụng cấu trúc thư mục có ý nghĩa từ quan điểm ứng dụng của bạn

  kiểm tra chính ở đây là rằng nó sẽ có thể xác định một tập tin chỉ bằng cách tìm kiếm tại PATH \ FILE một mình, w/out làm tra cứu siêu dữ liệu trong DB. Nếu bạn lưu trữ/truy cập mẫu dựa trên thời gian thì STORE \ DATE \ HH \ FILE sẽ có ý nghĩa, nếu bạn có tệp được sở hữu bởi người dùng, thì có lẽ STORE \ < Chữ số N đầu tiên của UID> \ UID \ FILE sẽ làm cho giác quan.

• giao dịch sử dụng cho các hoạt động tập tin/metadata

  ví dụ: bắt đầu ghi tập tin siêu dữ liệu TRX, hãy thử viết một tập tin để FS, trên thành công cam kết TRX, rollback về lỗi. Việc chăm sóc tối đa cần được thực hiện để tránh tình huống khi bạn có siêu dữ liệu tệp trong DB và không có tệp nào trong FS và vise-verso.

• sử dụng nhiều gốc địa điểm lưu trữ

  ví dụ STORE01 \ STORE02 \ CỬA HÀNG \ - điều này có thể giúp phát triển (và sau đó với nhân rộng ra). Có thể một số nhà phát triển sẽ sử dụng một DB trung tâm và lưu trữ tệp cục bộ cho máy của họ. Sử dụng STORE ngay từ đầu sẽ giúp tránh tình huống khi siêu dữ liệu/tập tin chải. sẽ có hiệu lực trong một trường hợp của một ứng dụng, và không hợp lệ trong khác ..

• bao giờ lưu trữ pathes tuyệt đối trong DB