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

Question

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ó lẽ không chỉnh sửa/thay đổi kích 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 thả một tài nguyên .NET cho điều đó trong phần bình luận hay như vậy). Tôi tự hỏi bây giờ đâu là nơi tốt nhất để lưu trữ hình ảnh đã tải lên.

• 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 có đường dẫn chính xác đến hình ảnh đó.

• Hoặc, lưu trữ hình ảnh trong bảng sử dụng loại 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 và nhược điểm của 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 nghiệp vụ 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 nghiệp vụ (vì lý do bảo mật) Tôi thích b) vì tất cả thông tin ở một nơi và truy cập dễ dàng bằng truy vấn. Mặt khác cơ sở dữ liệu sẽ rất lớn rất sớm. Gia công phần mềm mà dữ liệu có thể khó khăn hơn.

Answer 1

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

Có một số vấn đề với lưu trữ tệp trên cơ sở dữ liệu - tệp thường lớn hơn nhiều so với hàng trung bình của bạn - tập hợ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 một công cụ lưu trữ sử dụng các khóa bảng để ghi (ví dụ ISAM), bảng tệp của bạn có thể bị khóa thường tùy thuộc vào kích cỡ/tỷ lệ tệp bạn đang lưu trữ ở đó.

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

Answer 2

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

Nếu thời gian đến khi điều này không quy mô cho bạn thì bạn có thể điều tra cơ chế lưu vào bộ nhớ cache.

Answer 3

Hầu hết các hiện thực là lựa chọn A.

Với tùy chọn B, bạn mở một lon toàn bộ lớn của whoop4ss khi bạn marshall những bit từ cơ sở dữ liệu vào một cái gì đó có thể được hiển thị trên trình duyệt ... Ngoài ra, nếu db là xuống, hình ảnh không có sẵn.

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

Chúng tôi đang thực hiện với tùy chọn A vì chúng ta không có thời gian hay nguồn lực để làm tùy chọn B.

Answer 4

Flickr sử dụng hệ thống tập tin -they thảo luận về lý do here

Answer 5

Tuyệt đối, tích cực lựa chọn A. Khác đã đề cập rằng cơ sở dữ liệu thường không giải quyết tốt với 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 vùng RAID, truyền hình ảnh trên nhiều ổ đĩa, thậm chí là truyền bá chúng trên các máy chủ khác nhau về mặt địa lý.

Một ưu điểm khác là sao lưu/sao lưu cơ sở dữ liệu của bạn sẽ trở nên quái dị.

Answer 6

Để tự động đổ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ý nội dung/ảnh nguồn mở lớn ... và tôi tin rằng có một số phần mở rộng .net cho nó.

Answer 7

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 số phụ trợ khác nhau, và chúng tôi luôn luôn kết thúc trở lại tùy chọn A (lưu trữ hệ thống tệp).

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

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

Một lưu ý khác: nếu bạn đang sử dụng bộ nhớ dựa trên NTFS (máy chủ cửa sổ, v.v.), bạn có thể cân nhắc tìm cách sắp xếp hàng nghìn và hàng nghìn tệp trong một thư mục. Tôi không chắc chắn 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 có ai biết thêm về điều này thì 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 để chia nhỏ mọi thứ một chút. ngày tạo thường hoạt động tốt cho việc này:

Images/2008/12/17/.jpg

... này cung cấp một mức độ khá tách biệt, và cũng có thể giúp một chút trong gỡ lỗi. Khách hàng Explorer và FTP cũng có thể bị nghẹt thở một chút khi có những thư mục thực sự lớn.

CHỈNH SỬA: Chỉ cần lưu ý nhanh cho năm 2017, trong các phiên bản gần đây của SQL Server, có các tùy chọn mới để xử lý nhiều BLOB.

Answer 8

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

Một điều khác mà tôi khuyên bạn nên thay đổi ngay lập tức tên tệp từ những gì người dùng đã đặt tên cho ả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 bất kỳ ký tự lạ nào của người dùng để tránh các biến chứng trong tương lai.

Answer 9

Chắc chắn định lạ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ân phối bởi máy chủ không mong muốn - ví dụ: lỗ hổng GIFAR 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 tập lệnh cross-site. Thay đổi kích thước hình ảnh thường ngăn chặn điều này, vì nó chèn mã nhúng. Trong khi cuộc tấn công này đã được cố định bởi các bản vá lỗi JVM, việc phân phối các tệp nhị phân một cách ngây thơ mà không cần quét chúng sẽ mở ra cho bạn toàn bộ các lỗ hổng. Hãy nhớ rằng, hầu hết các máy quét virus chỉ có thể chạy trên hệ thống tập tin nếu bạn lưu trữ các tệp nhị phân của mình trong DB, bạn sẽ không thể chạy một máy quét chống lại chúng một cách dễ dàng.

Answer 10

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

Ưu điểm:

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

Nhược điểm:

• mysqldump nay mất một thời gian looooong vì có 500MB dữ liệu tệp trong một trong các bảng.
• Nói chung không phải là rất nhớ/CPU hiệu quả khi so sánh với hệ thống tập tin

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

Answer 11

Tùy 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 để đổ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

Answer 12

Nếu chúng là các tệp nhỏ sẽ không cần chỉnh sửa thì tùy chọn B không phải là tùy chọn không hợp lệ. Tôi thích điều này để viết logic để lưu trữ các tập tin và đối phó với các vấn đề cấu trúc thư mục điên. Có rất nhiều tệp 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à đặt cược tốt nhất của bạn.

Đối với hầu hết các trường hợp, đó là vấn đề ưu tiên, nhưng nếu bạn đi tùy chọn A, chỉ cần làm 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 làm cho bảng có dữ liệu BLOB được ở trong cơ sở dữ liệu và/hoặc nhóm tệp riêng của nó. Điều này sẽ giúp bảo trì, đặc biệt là sao lưu/phục hồi. Dữ liệu thông thường của bạn có thể là khá nhỏ, trong khi dữ liệu hình ảnh của bạn sẽ là lớn theo thời gian.

Answer 13

Có một cách tiếp cận lai trong SQL Server 2008 được gọi là filestream datatype đã được nói đến trên RunAs Radio #74, giống như là tốt nhất của cả hai thế giới. Hầu hết mọi người không có thuốc uống 2008, nhưng nếu bạn làm, tùy chọn này trông khá thú vị

Answer 14

Vì lý do bảo mật, cách tốt nhất là tránh các sự cố gây ra bởi IE's Content Sniffing. có thể được thực hiện trong ngữ cảnh của 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 loại tấn công này. This answer có một số ý tưởng khác.

Answer 15

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 các tập lệnh (rất quan trọng) và (đọc, ghi) được bảo vệ vì không được truy cập trong yêu cầu http.

Tôi hy vọng điều này sẽ giúp bạn.

Answer 16

Lợi ích duy nhất cho tùy chọn B có tất cả dữ liệu trong một hệ thống, nhưng đó là một 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 sẽ thích nó như thế nào?

Trừ khi bạn có một số trường hợp đặc biệt:

• Kinh doanh logic 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 quan hệ).
• Dữ liệu hàng loạt thuộc về bộ nhớ (hệ thống tệp hoặc khác).

Nó không phải là cần thiết để sử dụng hệ thống tập tin để giữ các tập tin. Thay vào đó bạn có thể sử dụng lưu trữ đám mây (như Amazon S3) hay Infrastructure-as-a-dịch vụ trên đầu trang của nó (như Uploadcare):

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

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

Answer 17

Đây là cơ bản tôi làm.

1. Lưu trữ ảnh đã tải lên trong thư mục hoặc bộ nhớ tạm thời.
2. Xử lý hình ảnh đó trước khi lưu trữ vĩnh viễn hình ảnh đó. 2.1. Hiệu 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 etc.
3. Đóng gói tất cả các tệp hình ảnh đã xử lý (từ một tệp) bên trong thư mục có tên thư mục là id, sẽ đượ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 làm tên hình ảnh).
4. Tạo yyyy/mm/dpath thư mục 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 hình ảnh id thư mục tới path thư mục. (Thư mục đường dẫn có thể nằm trong thư mục/var/web-content.)
6. Đệm bộ đệm xóa hoặc xóa tệp tạm thời.

---

Khi bạn cần truy cập vào bất kỳ hình ảnh đề cập trong một tài liệu, bạn có đường dẫn và id của thư mục chứa các hình ảnh hơn. 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ó đệ quy.

Answer 18

Tùy 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.Tuy nhiên, đối với văn phòng nhỏ hoặc trung bình, lựa chọn tốt nhất là sử dụng một ứng dụng như Apple Photos hoặc Adobe Lighroom. Chúng 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. Tuy nhiên, đối với các tổ chức lớn, với yêu cầu mạnh về dung lượng lưu trữ và số lượng người dùng cao, bạn nên khởi tạo một plataform Quản lý nội dung bằng Quản lý nội dung 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 thức đơn giản hóa để giúp chúng trở lại. 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.

Answer 19

Tôi biết đây là một bài đăng 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 cho người mới chơ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ì kể từ khi lưu trữ tệp cho một số lưu trữ chia sẻ vẫn đủ. Vấn đề xuất phát từ một trang web động khi trở nê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 tin như hình ảnh là nhận được 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 động. Thông thường, hình ảnh này đã được tối ưu hóa trước khi tải lên, chắc chắ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 khó dự đoán kích thước. Người dùng có thể tải lên những hình ảnh lớn chỉ dành cho nội dung nhỏ bằng cách thay đổi kích thước khung hình nhưng không thay đổi kích thước hình ảnh.

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

1. Đừng cho phép người dùng tải lên 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 tin trước khi họ có thể nhúng vào nội dung. Phương thức này được gọi là Trình quản lý tệp.

2. Sử dụng chức năng hình ảnh cắt để 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ả khi 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ắt. Chúng ta có thể định nghĩa kích thước ở phía máy chủ và chỉ chấp nhận ví dụ 500Kb hoặc thấp hơn.

Hiện tại, đó 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:

• Cách xử lý dung lượng lưu trữ hình ảnh lớn?
• Đổi kích thước hoặc thay đổi tiện ích.
• Trang web hoặc thương mại điện tử lớn hoặc trung bình xử lý lưu trữ tệp cho hình ảnh của họ như thế nào?

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

1. Di chuyển từ cổ phiếu VPS lưu trữ. 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 đó. Đây không phải là khó khăn 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 hơi tốn kém. 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ữ tệp web của mình bao nhiêu tùy thích. Câu hỏi, cách tải tệp lên CDN từ trang web của chúng tôi?

Đừng lo, 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 từ/đến trang web của bạn. Bạn sẽ nhận được một API và nhiều hơn 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 giới hạn. Nhưng điều đó sẽ ổn cho điểm bắt đầu. Vấn đề duy nhất là bởi vì 'người ta không bao giờ thử'.

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