2011-11-18 42 views
6

thể trùng lặp:
Storing Images in DB - Yea or Nay?
Images in database vs file systemLưu trữ tệp hình ảnh hoặc URL trong cơ sở dữ liệu MySQL? Cái nào tốt hơn?

Tôi đã phát triển một ứng dụng web sử dụng công nghệ RIA (Flex + PHP + MySQL + Ajax) và bây giờ tôi đang ở trong một tiến thoái lưỡng nan về tệp hình ảnh.

Tôi sử dụng một số hình ảnh trong ứng dụng Flex của mình, vì vậy tôi nghĩ "nó có thể tuyệt vời nếu tôi lưu trữ chúng vào cơ sở dữ liệu, và sau đó truy xuất nó; consecuently, duy trì quá trình nên dễ dàng hơn". Nhưng, đây là tình trạng khó xử của tôi:

Tôi có nên lưu trữ URL thực của hình ảnh của mình hay sẽ tốt hơn nếu tôi lưu trữ trực tiếp hình ảnh?

Ví dụ, nên bảng Cars của tôi trông giống như:

ID (autonumeric) | Source (văn bản)

hoặc như thế này?

ID (tự động) | Image (longblob hoặc blob)

Tôi biết rằng đây là những người tuyệt vời mà có thể trả lời cho tôi câu hỏi này, giải thích cho tôi mà là tốt hơn và tại sao :)

+0

URL, chắc chắn tốt hơn. – Mob

Trả lời

6

Cá nhân tôi khuyên bạn nên Lưu trữ hình ảnh trong cơ sở dữ liệu. Tất nhiên đó là cả lợi thế và bất lợi.

Ưu điểm của lưu trữ dữ liệu BLOB trong cơ sở dữ liệu:

  • Nó là dễ dàng hơn để giữ cho dữ liệu BLOB đồng bộ với các hạng mục còn lại ở hàng.
  • Dữ liệu BLOB được sao lưu bằng cơ sở dữ liệu. Có một hệ thống lưu trữ duy nhất có thể dễ dàng quản trị.
  • Dữ liệu BLOB có thể được truy cập thông qua hỗ trợ XML trong MySQL, có thể trả về biểu diễn mã hóa cơ sở 64 của dữ liệu trong luồng XML.
  • Hoạt động tìm kiếm văn bản đầy đủ của MySQL (FTS) có thể được thực hiện đối với các cột chứa dữ liệu ký tự cố định hoặc có độ dài thay đổi (bao gồm cả Unicode). Bạn cũng có thể thực hiện các thao tác FTS dựa trên dữ liệu dựa trên văn bản được định dạng chứa trong các trường hình ảnh — ví dụ, các tài liệu Microsoft Word hoặc Microsoft Excel.

Nhược điểm của Lưu trữ BLOB dữ liệu trong cơ sở dữ liệu:

Cẩn thận xem xét những gì các nguồn lực có thể được lưu trữ tốt hơn trên hệ thống tập tin chứ không phải là trong một cơ sở dữ liệu. Ví dụ hay là những hình ảnh thường được tham chiếu qua HTTP HREF. Điều này là do:

  • Truy xuất hình ảnh từ cơ sở dữ liệu chịu chi phí đáng kể so với sử dụng hệ thống tệp.
  • Lưu trữ đĩa trên cơ sở dữ liệu SAN thường đắt hơn dung lượng lưu trữ trên các đĩa được sử dụng trong các trang trại máy chủ Web.
+0

Tôi không phải là một chuyên gia về DBs ở tất cả, nhưng những gì về kết quả bộ nhớ đệm và sử dụng RAM máy chủ DB? Nó sẽ không tăng rất nhiều kể từ khi các đốm màu sẽ nhận được tất cả nạp vào ram? –

4

Theo nguyên tắc chung bạn wan't để giữ bạn cơ sở dữ liệu nhỏ, vì vậy chúng hoạt động tốt hơn (và sao lưu tốt hơn). Vì vậy, nếu bạn chỉ có thể lưu trữ một tham chiếu hệ thống tập tin (đường dẫn + tên tệp) hoặc URL trong DB, điều đó sẽ tốt hơn.

+0

Không đồng ý. Cơ sở dữ liệu lớn có thể thực hiện tốt cũng như các cơ sở dữ liệu nhỏ nếu được quản lý chính xác. Cơ sở dữ liệu cũng là một nền tảng lý tưởng cho việc lưu trữ hình ảnh; Truy cập trực tiếp từ DB có thể giải quyết rất nhiều vấn đề khi sử dụng các hệ thống lớn hơn, chẳng hạn như nhiều máy chủ web, nơi bạn phải bắt đầu sử dụng bộ nhớ chia sẻ (có vấn đề riêng) hoặc sao chép tệp (nhiều vấn đề hơn). – ChrisBint

+1

@ChrisBint Nếu bạn có một thư viện web ví dụ, và lưu trữ hình ảnh trên DB, tất cả công việc và lưu lượng truy cập sẽ phải đi qua máy chủ DB. Nếu bạn lưu trữ đường dẫn/url, bạn có thể chia sẻ tải với nhiều máy chủ web mà bạn đang nói đến.Nhưng mỗi tình huống đòi hỏi những cách tiếp cận khác nhau, do đó tôi đã nói rằng đó là một quy luật chung không phải là một luật đặt trong đá. –

+0

Bạn không thể "chia sẻ tải" với nhiều máy chủ vì bạn cần tìm ra cách chia sẻ tệp. NFS? Không đời nào ... nếu bạn mất phần chia sẻ NFS thì sao? Ít nhất là với một DB, bạn đang đồng bộ hóa chúng và có thể sử dụng một master-slave nếu cần thiết. – luckytaxi

0

tôi muốn lưu trữ các url, đó là dữ liệu ít hơn và đó có nghĩa là một cơ sở dữ liệu nhỏ hơn và dữ liệu nhanh hơn lấy từ nó;)

3

của nó có thể là một vấn đề sở thích cá nhân.

Như một quy tắc chung, tốt hơn nên giữ cơ sở dữ liệu nhỏ. Tuy nhiên khi bạn đến với các ứng dụng doanh nghiệp, họ quy định thêm hình ảnh trực tiếp vào cơ sở dữ liệu. Nếu bạn đặt chúng trên hệ thống tệp, db và hệ thống tệp của bạn có thể không đồng bộ.

CMS lớn hơn sẽ quy định đặt những tệp đó trong db. Tuy nhiên, hãy lưu ý rằng điều này yêu cầu kích thước DB lớn hơn khi mọi thứ đang phát triển ...

Khi bạn chỉ lưu url và tên, hãy đảm bảo rằng chúng sẽ không thay đổi trong tương lai.

Với các tệp được lưu trữ trong cơ sở dữ liệu, bạn có thể triển khai bảo mật dễ dàng hơn và bạn không phải lo lắng về tên tệp trùng lặp.

1

Tôi đã sử dụng để lưu trữ đường dẫn vào URL, nhưng sau đó thêm máy chủ web bổ sung vào kết hợp được chứng minh là ít lý tưởng. Đối với một điều, bạn sẽ phải chia sẻ đường dẫn đến nơi lưu trữ hình ảnh. Chúng tôi đã sử dụng NFS và nó trở nên chậm chạp sau một thời gian. Chúng tôi đã thử đồng bộ hóa các tệp từ máy chủ web này đến máy chủ web khác nhưng quá trình này trở nên rườm rà.

Có nói rằng, tôi sẽ lưu trữ chúng trong DB. Tôi đã chuyển tất cả lưu trữ hình ảnh/tệp của mình sang MongoDB. Tôi biết điều này không đáp ứng nhu cầu của bạn nhưng chúng tôi đã thử tất cả (thậm chí S3) và chúng tôi không hài lòng với các giải pháp khác. Nếu chúng tôi phải làm vậy, tôi chắc chắn sẽ ném chúng vào trong MySQL.

0

Cá nhân, tôi đã luôn lưu trữ URL.

Không có lý do thực sự nào để không lưu trữ hình ảnh trực tiếp trong cơ sở dữ liệu, nhưng có những lợi ích để không lưu trữ nó trong cơ sở dữ liệu.

Bạn linh hoạt hơn khi bạn không lưu trữ hình ảnh trong cơ sở dữ liệu. Bạn có thể dễ dàng di chuyển xung quanh và chỉ cập nhật URL trong tệp. Vì vậy, nếu bạn muốn di chuyển hình ảnh từ máy chủ web của bạn sang một dịch vụ như Flickr hoặc Amazon Web Services, nó sẽ dễ dàng như việc cập nhật liên kết đến các tệp mới. Điều đó cũng cho phép bạn dễ dàng truy cập vào mạng phân phối nội dung để hình ảnh được gửi đến người dùng cuối nhanh hơn.

Các vấn đề liên quan