Nơi tốt nhất để lưu trữ hình ảnh được tải lên, cơ sở dữ liệu SQL hoặc hệ thống tệp đĩa là gì?

Tôi đang viết một ứng dụng cho phép người dùng tải hình ảnh lên máy chủ. Tôi mong đợi khoảng 20 hình ảnh mỗi ngày tất cả jpeg và có thể không được chỉnh sửa / thay đổi kích thước. (Đây là một câu hỏi khác, làm thế nào để thay đổi kích thước hình ảnh ở phía máy chủ trước khi lưu trữ. Có lẽ ai đó có thể vui lòng bỏ tài nguyên .NET cho nhận xét đó trong bình luận hoặc hơn). Bây giờ tôi tự hỏi nơi tốt nhất để lưu trữ hình ảnh được tải lên là gì.

• Lưu trữ hình ảnh dưới dạng tệp trong hệ thống tệp và tạo bản ghi trong bảng với đường dẫn chính xác đến hình ảnh đó.

• Hoặc, lưu trữ hình ảnh trong bảng bằng cách sử dụng kiểu dữ liệu "hình ảnh" hoặc "dữ liệu nhị phân" của máy chủ cơ sở dữ liệu.

Tôi thấy ưu điểm và nhược điểm ở cả hai. Tôi thích a) vì tôi có thể dễ dàng di chuyển các tệp và chỉ cần thay đổi mục nhập bảng. Mặt khác, tôi không thích lưu trữ dữ liệu kinh doanh trên máy chủ web và tôi thực sự không muốn kết nối máy chủ web với bất kỳ nguồn dữ liệu nào khác chứa dữ liệu kinh doanh (vì lý do bảo mật) Tôi thích b) vì tất cả thông tin là ở một nơi và dễ dàng truy cập bằng một truy vấn. Mặt khác, cơ sở dữ liệu sẽ sớm trở nên rất lớn. Gia công dữ liệu đó có thể khó khăn hơn.

Tôi thường lưu trữ các tệp trên hệ thống tệp, vì đó là những gì nó có, mặc dù có trường hợp ngoại lệ. Đối với các tệp, hệ thống tệp là giải pháp linh hoạt và hiệu quả nhất (thường).

Có một vài vấn đề với việc lưu trữ tệp trên cơ sở dữ liệu - các tệp thường lớn hơn nhiều so với hàng trung bình của bạn - các tập kết quả chứa nhiều tệp lớn sẽ tiêu tốn rất nhiều bộ nhớ. Ngoài ra, nếu bạn sử dụng công cụ lưu trữ sử dụng khóa bảng để ghi (ví dụ ISAM), bảng tệp của bạn có thể bị khóa thường xuyên tùy thuộc vào kích thước / tốc độ của tệp bạn đang lưu trữ ở đó.

Về bảo mật - Tôi thường lưu trữ các tệp trong một thư mục nằm ngoài thư mục gốc (không thể truy cập thông qua yêu cầu http) và phân phát chúng thông qua tập lệnh kiểm tra ủy quyền thích hợp trước.

Lợi ích duy nhất cho tùy chọn B là có tất cả dữ liệu trong một hệ thống, nhưng đó là lợi ích sai! Bạn có thể lập luận rằng mã của bạn cũng là một dạng dữ liệu và do đó cũng có thể được lưu trữ trong cơ sở dữ liệu - bạn muốn nó như thế nào?

Trừ khi bạn có một số trường hợp duy nhất:

• Logic kinh doanh thuộc về mã.
• Dữ liệu có cấu trúc thuộc về cơ sở dữ liệu (quan hệ hoặc không liên quan).
• Dữ liệu hàng loạt thuộc về lưu trữ (hệ thống tập tin hoặc khác).

Không cần thiết phải sử dụng hệ thống tập tin để giữ tập tin. Thay vào đó, bạn có thể sử dụng lưu trữ đám mây (như Amazon S3 ) hoặc Cơ sở hạ tầng dưới dạng dịch vụ trên đầu trang (chẳng hạn như Uploadcare ):

https://uploadcare.com/upload-api-cloud-st Storage-and-cdn /

Nhưng lưu trữ các tập tin trong cơ sở dữ liệu là một ý tưởng tồi.

Flickr sử dụng hệ thống tập tin - họ thảo luận về lý do tại đây

Tôi biết đây là một bài viết cũ. Nhưng nhiều khách truy cập vào trang này không nhận được gì liên quan đến câu hỏi. Đặc biệt là đối với một người mới.

Cách tải lên và lưu trữ hình ảnh hoặc tệp trong trang web của chúng tôi:

Đối với một trang web tĩnh, có thể không có vấn đề gì vì việc lưu trữ tệp cho một số lưu trữ chia sẻ vẫn còn đầy đủ. Vấn đề xuất phát từ một trang web động khi nó lớn hơn. Lớn hơn trong cơ sở dữ liệu có thể được xử lý, nhưng lớn hơn trong tệp như hình ảnh đang trở thành một vấn đề. Có hai loại hình ảnh trong một trang web:

1. Hình ảnh đến từ quản trị viên cho blog năng động. Thông thường, những hình ảnh này đã được tối ưu hóa trước khi tải lên.

2. Hình ảnh từ người dùng trong trường hợp người dùng được phép tải lên hình ảnh như hình đại diện. Hoặc người dùng có thể tạo nội dung blog và đặt một số hình ảnh từ trình soạn thảo văn bản. Loại hình ảnh này rất khó để dự đoán kích thước. Người dùng có thể tải lên hình ảnh lớn chỉ cho nội dung nhỏ bằng cách thay đổi kích thước kích thước xem nhưng không thay đổi kích thước kích thước hình ảnh.

Bằng cách bỏ qua mục không. 1 ở trên, giải pháp nhanh chóng cho mục số. 2 có thể được giải quyết tạm thời bằng các mẹo sau nếu chúng tôi không có chức năng tối ưu hóa hình ảnh trong trang web của mình:

1. Không cho phép người dùng tải trực tiếp từ trình chỉnh sửa văn bản bằng cách chuyển hướng họ đến thư viện hình ảnh. Trên trang này, người dùng phải tải lên tệp trước khi họ có thể nhúng vào nội dung. Phương pháp này được gọi là Trình quản lý tệp.

2. Sử dụng chức năng cắt ảnh cho người dùng để tải lên hình ảnh. Điều này sẽ giới hạn kích thước hình ảnh ngay cả người dùng tải lên tệp rất lớn. Hình ảnh cuối cùng là kết quả của hình ảnh được cắt. Chúng tôi có thể xác định kích thước ở phía máy chủ và chỉ chấp nhận ví dụ 500Kb trở xuống.

Bây giờ, đó chỉ là tạm thời. Đối với giải pháp cuối cùng, câu hỏi được lặp lại:

• Làm thế nào để xử lý một lưu trữ hình ảnh lớn?
• Thay đổi kích thước hoặc thay đổi phần mở rộng.
• Làm thế nào một trang web lớn hoặc trung bình hoặc thương mại điện tử xử lý việc lưu trữ tệp cho hình ảnh của họ?

Những gì chúng ta có thể làm sau đó:

1. Di chuyển từ chia sẻ lưu trữ VPS. Không đủ? Sau đó, cao hơn bằng cách nâng cấp lên Chuyên dụng.

2. Tạo máy chủ của riêng bạn để lưu trữ tệp. Googling để làm điều đó. Điều này không khó như bạn nghĩ. Một số người làm điều đó cho trang web của họ.

3. Cách dễ dàng là sử dụng dịch vụ lưu trữ tệp CDN.

Được rồi, 1 và 2 là một chút đắt tiền. Nhưng không có 3 tôi nghĩ là giải pháp tốt nhất.

Một số dịch vụ CDN cho phép bạn lưu trữ nhiều tệp web như bạn muốn.

Câu hỏi, "làm thế nào để tải tệp lên CDN từ trang web của chúng tôi?"

Đừng lo lắng, khi bạn đăng ký, thường là miễn phí, bạn sẽ nhận được hướng dẫn cách tải tệp lên và nhận liên kết của họ từ / đến trang web của bạn. Bạn sẽ nhận được một API và hơn thế nữa. Dễ thôi.

Một số nhà cung cấp cung cấp cho chúng tôi dịch vụ miễn phí trong 14 ngày với dung lượng và băng thông hạn chế. Nhưng điều đó sẽ ổn cho điểm bắt đầu. Vấn đề duy nhất là vì "mọi người không bao giờ thử".

Hy vọng nó sẽ giúp cho người mới.

Chúng tôi đã có khách hàng nhấn mạnh vào tùy chọn B (lưu trữ cơ sở dữ liệu) một vài lần trên một vài phụ trợ khác nhau và cuối cùng chúng tôi luôn quay trở lại tùy chọn A (lưu trữ hệ thống tệp).

Các BLOB lớn như thế chưa được xử lý đủ tốt ngay cả bởi SQL Server 2005, đây là phiên bản mới nhất mà chúng tôi đã thử.

Cụ thể, chúng tôi đã thấy sự phình to nghiêm trọng và tôi nghĩ có thể khóa các vấn đề.

Một lưu ý khác: nếu bạn đang sử dụng bộ lưu trữ dựa trên NTFS (máy chủ windows, v.v.), bạn có thể cân nhắc tìm cách xoay quanh hàng ngàn và hàng ngàn tệp trong một thư mục. Tôi không chắc tại sao, nhưng đôi khi hệ thống tập tin không đối phó tốt với tình huống đó. Nếu ai biết nhiều hơn về điều này, tôi rất thích nghe nó.

Nhưng tôi luôn cố gắng sử dụng các thư mục con để phá vỡ mọi thứ một chút. Ngày tạo thường hoạt động tốt cho việc này:

Hình ảnh / 2008/12/17 / .jpg

... Điều này cung cấp một mức độ tách biệt tốt, và cũng giúp một chút trong quá trình gỡ lỗi. Các máy khách Explorer và FTP giống nhau có thể bị nghẹt một chút khi có các thư mục thực sự lớn.

BIÊN TẬP: Chỉ là một lưu ý nhanh cho năm 2017, trong các phiên bản gần đây hơn của SQL Server, có các tùy chọn mới để xử lý nhiều BLOB được cho là để tránh những nhược điểm mà tôi đã thảo luận.

EDIT: Ghi chú nhanh cho năm 2020, Blob Storage trong AWS / Azure / etc cũng đã là một lựa chọn trong nhiều năm nay. Điều này rất phù hợp với nhiều dự án dựa trên web vì nó rẻ và nó thường có thể đơn giản hóa một số vấn đề xung quanh việc triển khai, mở rộng ra nhiều máy chủ, gỡ lỗi các môi trường khác khi cần thiết, v.v.

Gần đây tôi đã tạo một ứng dụng PHP / MySQL lưu trữ các tệp PDF / Word trong bảng MySQL (lớn tới 40 MB cho mỗi tệp cho đến nay).

Ưu điểm:

• Các tệp đã tải lên được sao chép vào máy chủ sao lưu cùng với mọi thứ khác, không cần chiến lược sao lưu riêng biệt (yên tâm).
• Việc thiết lập máy chủ web đơn giản hơn một chút vì tôi không cần phải có thư mục tải lên / và cho tất cả các ứng dụng của mình biết nó đang ở đâu.
• Tôi có thể sử dụng các giao dịch cho các chỉnh sửa để cải thiện tính toàn vẹn dữ liệu - Tôi không phải lo lắng về các tệp bị mồ côi và bị thiếu

Nhược điểm:

• mysqldump hiện mất một thời gian ngắn vì có 500MB dữ liệu tệp trong một trong các bảng.
• Nhìn chung, bộ nhớ / cpu không hiệu quả lắm khi so sánh với hệ thống tập tin

Tôi gọi việc thực hiện của tôi là thành công, nó quan tâm đến các yêu cầu sao lưu và đơn giản hóa bố cục của dự án. Hiệu suất là tốt cho 20-30 người sử dụng ứng dụng.

Tôi sử dụng hình ảnh được tải lên trên trang web của tôi và tôi chắc chắn sẽ nói tùy chọn a).

Một điều khác tôi rất khuyến khích là ngay lập tức thay đổi tên tệp từ những gì người dùng đã đặt tên cho ảnh, thành một thứ dễ quản lý hơn. Ví dụ một cái gì đó với ngày và thời gian để xác định duy nhất mỗi hình ảnh.

Nó cũng giúp loại bỏ tên tệp của người dùng về bất kỳ ký tự lạ nào để tránh các biến chứng trong tương lai.

Chắc chắn thay đổi kích thước hình ảnh và kiểm tra định dạng của nó nếu bạn có thể. Đã có trường hợp các tệp độc hại được tải lên và phục vụ bởi các máy chủ không mong muốn - ví dụ: QUÀ TẶNG lỗ hổng cho phép bạn ẩn một applet java độc hại trong tệp GIF, sau đó có thể đọc cookie trong ngữ cảnh hiện tại và gửi chúng đến một trang web khác cho một cuộc tấn công kịch bản chéo trang web. Thay đổi kích thước hình ảnh thường ngăn chặn điều này, vì nó trộn mã nhúng. Mặc dù cuộc tấn công này đã được sửa bởi các bản vá JVM, nhưng việc phục vụ các tệp nhị phân một cách ngây thơ mà không xóa chúng sẽ mở ra cho bạn một loạt các lỗ hổng.

Hãy nhớ rằng, hầu hết các máy quét vi-rút chỉ có thể chạy với hệ thống tệp - nếu bạn lưu trữ nhị phân của mình trong DB, bạn sẽ không thể chạy máy quét chống lại chúng rất dễ dàng.

Có một cách tiếp cận hỗn hợp trong SQL Server 2008 được gọi là kiểu dữ liệu filestream đã được nói đến trên RunAs Radio # 74 , giống như kiểu tốt nhất của cả hai thế giới. Hầu hết mọi người không có otion 2008, nhưng nếu bạn làm thế, tùy chọn này trông khá tuyệt

Điều này về cơ bản là tôi làm.

1. Lưu trữ một hình ảnh được tải lên trong thư mục tạm thời hoặc bộ nhớ.
2. Xử lý hình ảnh đó trước khi lưu trữ vĩnh viễn. 2.1. Chỉnh màu 2.2. Nén 2.3. Tạo một số bản sao dựa trên kích thước hình ảnh 2.4. Đổi tên với hậu tố .xl, .lg, .md, .sm, v.v.
3. Đóng gói tất cả các tệp hình ảnh được xử lý (từ một tệp) trong một thư mục có tên thư mục idsẽ được lưu trữ trong cơ sở dữ liệu cho bất kỳ hàng / tài liệu nào cùng với image file name(hoặc có thể là tên ngẫu nhiên dưới dạng tên hình ảnh).
4. Tạo thư mục yyyy / mm / d path nếu không tồn tại. Ví dụ 2016/08/21. Hãy nhớ rằng đường dẫn và lưu trữ trong cơ sở dữ liệu cho cùng một tài liệu và hàng.
5. Di chuyển idthư mục hình ảnh vào paththư mục. (Thư mục đường dẫn có thể được đặt trong thư mục / var / web-content.)
6. Xóa bộ nhớ đệm hoặc xóa tập tin tạm thời.

Khi bạn cần truy cập bất kỳ hình ảnh nào được đề cập trong tài liệu, bạn có đường dẫn và id của thư mục hơn là chứa hình ảnh. Ví dụ/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg

Bằng cách này nếu bạn phải xóa tất cả các tệp hình ảnh đã xử lý, chỉ cần xóa thư mục và nội dung của nó được đệ quy.

Hầu hết các triển khai là tùy chọn A.

Với tùy chọn B, bạn mở toàn bộ lon whoop4ss lớn khi bạn sắp xếp các bit đó từ cơ sở dữ liệu vào một thứ có thể hiển thị trên trình duyệt ... Ngoài ra, nếu db bị hỏng, hình ảnh không khả dụng.

Tôi không nghĩ rằng không gian quá nhiều vấn đề ... Ổ đĩa Terabyte bây giờ là vài trăm đô la.

Chúng tôi đang triển khai với tùy chọn A vì chúng tôi không có thời gian hoặc tài nguyên để thực hiện tùy chọn B.

Để tự động thay đổi kích thước, hãy thử hình ảnh ... nó được sử dụng cho nhiều hệ thống quản lý ảnh / nội dung nguồn mở lớn ... và tôi tin rằng có một số phần mở rộng .net cho nó.

Chúng tôi sử dụng A. Tôi sẽ đặt nó trên một ổ đĩa chung (trừ khi bạn không có kế hoạch chạy nhiều hơn một máy chủ).

Nếu thời gian đến khi điều này sẽ không mở rộng cho bạn thì bạn có thể điều tra các cơ chế lưu trữ.

Hoàn toàn, tùy chọn tích cực A. Những người khác đã đề cập rằng cơ sở dữ liệu thường không xử lý tốt các BLOB, cho dù chúng được thiết kế để làm như vậy hay không. Hệ thống tập tin, mặt khác, sống cho công cụ này. Bạn có tùy chọn sử dụng phân loại RAID, trải rộng hình ảnh trên nhiều ổ đĩa, thậm chí trải rộng chúng trên các máy chủ khác nhau về mặt địa lý.

Một lợi thế khác là sao lưu / sao chép cơ sở dữ liệu của bạn sẽ rất quái dị.

Lựa chọn A.

Khi hình ảnh được tải, bạn có thể xác minh định dạng và thay đổi kích thước trước khi lưu. Có một số mẫu mã .Net để thay đổi kích thước hình ảnh trên http://www.codeproject.com . Ví dụ: http://www.codeproject.com/KB/cs/Photo_Resize.aspx

Vì lý do bảo mật, cách tốt nhất là tránh các sự cố do Nội dung đánh hơi của IE có thể cho phép kẻ tấn công tải lên JavaScript bên trong các tệp hình ảnh, có thể được thực thi trong ngữ cảnh trang web của bạn. Vì vậy, bạn có thể muốn chuyển đổi hình ảnh (cắt / thay đổi kích thước chúng) bằng cách nào đó trước khi lưu trữ chúng để ngăn chặn kiểu tấn công này. Câu trả lời này có một số ý tưởng khác.

Vâng, tôi có một dự án tương tự nơi người dùng tải tệp lên máy chủ. Theo quan điểm của tôi, tùy chọn a) là giải pháp tốt nhất do nó linh hoạt hơn. Những gì bạn phải làm là lưu trữ hình ảnh trong một thư mục được bảo vệ được phân loại bởi các thư mục con. Thư mục chính phải được quản trị viên thiết lập vì nội dung không được chạy tập lệnh (rất quan trọng) và (đọc, ghi) được bảo vệ vì không thể truy cập được trong yêu cầu http.

Tôi hy vọng cái này sẽ giúp bạn.

Nếu chúng là những tệp nhỏ không cần chỉnh sửa thì tùy chọn B không phải là một lựa chọn tồi. Tôi thích điều này để viết logic để lưu trữ các tập tin và xử lý các vấn đề cấu trúc thư mục điên rồ. Có rất nhiều tập tin trong một thư mục là xấu. emkay

Nếu các tệp lớn hoặc yêu cầu chỉnh sửa liên tục, đặc biệt là từ các chương trình như văn phòng, thì tùy chọn A là lựa chọn tốt nhất của bạn.

Trong hầu hết các trường hợp, đó là vấn đề ưu tiên, nhưng nếu bạn chọn tùy chọn A, chỉ cần tạo lại các thư mục không có quá nhiều tệp trong đó. Nếu bạn chọn tùy chọn B, thì hãy tạo bảng có dữ liệu BLOBed trong cơ sở dữ liệu và / hoặc nhóm tệp của chính nó. Điều này sẽ giúp bảo trì, đặc biệt là sao lưu / khôi phục. Dữ liệu thông thường của bạn có thể khá nhỏ, trong khi dữ liệu hình ảnh của bạn sẽ rất lớn theo thời gian.

Nó phụ thuộc vào yêu cầu của bạn, khối lượng đặc biệt, người dùng và tần suất tìm kiếm. Nhưng, đối với văn phòng nhỏ hoặc vừa, lựa chọn tốt nhất là sử dụng một ứng dụng như Apple Photos hoặc Adobe Lighroom. Họ chuyên lưu trữ, lập danh mục, lập chỉ mục và tổ chức loại tài nguyên này. Nhưng, đối với các tổ chức lớn, với yêu cầu cao về lưu trữ và số lượng người dùng cao, chúng tôi khuyên bạn nên khởi tạo một biểu đồ Quản lý nội dung với Quản lý tài sản kỹ thuật số, như Nuxeo hoặc Alfresco; cả hai đều cung cấp các tài nguyên rất tốt để quản lý khối lượng dữ liệu rất lớn với các phương pháp đơn giản hóa để truy xuất lại chúng. Và, rất quan trọng: có một tùy chọn (nguồn mở) miễn phí cho cả hai nền tảng.