Vì vậy, tôi đang sử dụng một ứng dụng lưu trữ hình ảnh rất nhiều trong DB. Quan điểm của bạn về điều này là gì? Tôi thuộc loại để lưu trữ vị trí trong hệ thống tệp hơn là lưu trữ trực tiếp trong DB.
Bạn nghĩ ưu / nhược điểm là gì?
Câu trả lời:
Tôi phụ trách một số ứng dụng quản lý nhiều TB hình ảnh. Chúng tôi thấy rằng lưu trữ đường dẫn tệp trong cơ sở dữ liệu là tốt nhất.
Có một vài vấn đề:
Như với hầu hết các vấn đề, nó không đơn giản như nó có vẻ. Có những trường hợp sẽ có ý nghĩa để lưu trữ hình ảnh trong cơ sở dữ liệu.
Mặt khác, có những vấn đề liên quan
Lưu trữ tập tin. Các kỹ sư của Facebook đã có một cuộc nói chuyện tuyệt vời về nó. Một mất đi là để biết giới hạn thực tế của các tập tin trong một thư mục.
Đây có thể là một chút khó khăn, nhưng nếu bạn đang sử dụng (hoặc dự định sử dụng) SQL Server 2008, tôi khuyên bạn nên xem loại dữ liệu FileStream mới .
FileStream giải quyết hầu hết các vấn đề xung quanh việc lưu trữ các tệp trong DB:
Tuy nhiên, "Mã hóa dữ liệu trong suốt" của SQL không mã hóa các đối tượng FileStream, vì vậy nếu đó là một sự cân nhắc, bạn có thể tốt hơn là chỉ lưu trữ chúng dưới dạng varbinary.
Từ bài viết MSDN:
Các câu lệnh Transact-SQL có thể chèn, cập nhật, truy vấn, tìm kiếm và sao lưu dữ liệu FILESTREAM. Giao diện hệ thống tệp Win32 cung cấp quyền truy cập trực tuyến vào dữ liệu.
FILESTREAM sử dụng bộ đệm hệ thống NT để lưu trữ dữ liệu tệp. Điều này giúp giảm bất kỳ ảnh hưởng nào mà dữ liệu FILESTREAM có thể có đối với hiệu suất của Engine Engine. Nhóm bộ đệm SQL Server không được sử dụng; do đó, bộ nhớ này có sẵn để xử lý truy vấn.
Đường dẫn tệp trong DB chắc chắn là con đường để đi - Tôi đã nghe câu chuyện từ những khách hàng bị TB hình ảnh rằng nó trở thành một cơn ác mộng khi cố gắng lưu trữ bất kỳ số lượng hình ảnh đáng kể nào trong DB - chỉ riêng hiệu suất đạt được là quá nhiều.
Theo kinh nghiệm của tôi, đôi khi giải pháp đơn giản nhất là đặt tên cho hình ảnh theo khóa chính . Vì vậy, thật dễ dàng để tìm thấy hình ảnh thuộc về một bản ghi cụ thể và ngược lại. Nhưng đồng thời bạn không lưu trữ bất cứ điều gì về hình ảnh trong cơ sở dữ liệu.
Bí quyết ở đây là không trở thành một người nhiệt tâm.
Một điều cần lưu ý ở đây là không ai trong trại hệ thống tệp pro đã liệt kê một hệ thống tệp cụ thể. Điều này có nghĩa là tất cả mọi thứ từ FAT16 đến ZFS đều đánh bại mọi cơ sở dữ liệu?
Không.
Sự thật là nhiều cơ sở dữ liệu đánh bại nhiều hệ thống tệp, ngay cả khi chúng ta chỉ nói về tốc độ thô.
Quá trình hành động chính xác là đưa ra quyết định đúng đắn cho kịch bản chính xác của bạn và để làm điều đó, bạn sẽ cần một số con số và một số ước tính ca sử dụng.
Ở những nơi bạn PHẢI đảm bảo tính toàn vẹn tham chiếu và tuân thủ ACID, việc lưu trữ hình ảnh trong cơ sở dữ liệu là bắt buộc.
Bạn không thể giao dịch đảm bảo rằng hình ảnh và siêu dữ liệu về hình ảnh đó được lưu trữ trong cơ sở dữ liệu tham chiếu đến cùng một tệp. Nói cách khác, không thể đảm bảo rằng tệp trên hệ thống tệp chỉ bị thay đổi cùng một lúc và trong cùng một giao dịch với siêu dữ liệu.
Như những người khác đã nói SQL 2008 đi kèm với loại Filestream cho phép bạn lưu tên tệp hoặc mã định danh dưới dạng con trỏ trong db và tự động lưu trữ hình ảnh trên hệ thống tệp của bạn, đây là một tình huống tuyệt vời.
Nếu bạn đang sử dụng cơ sở dữ liệu cũ hơn, thì tôi sẽ nói rằng nếu bạn lưu trữ dữ liệu đó dưới dạng dữ liệu blob, thì bạn thực sự sẽ không lấy bất cứ thứ gì ra khỏi cơ sở dữ liệu theo cách tìm kiếm các tính năng, vì vậy có lẽ tốt nhất để lưu trữ một địa chỉ trên một hệ thống tập tin và lưu trữ hình ảnh theo cách đó.
Bằng cách đó, bạn cũng tiết kiệm không gian trên hệ thống tệp của mình, vì bạn sẽ chỉ tiết kiệm được dung lượng chính xác hoặc thậm chí không gian được nén trên hệ thống tệp.
Ngoài ra, bạn có thể quyết định lưu với một số cấu trúc hoặc thành phần cho phép bạn duyệt các hình ảnh thô trong hệ thống tệp của mình mà không có bất kỳ lần truy cập db nào hoặc chuyển các tệp hàng loạt sang hệ thống khác, ổ cứng, S3 hoặc một kịch bản khác - cập nhật vị trí trong chương trình của bạn, nhưng giữ cấu trúc, một lần nữa mà không có nhiều điểm nhấn khi cố gắng đưa hình ảnh ra khỏi db của bạn khi cố gắng tăng dung lượng.
Có lẽ, nó cũng sẽ cho phép bạn ném một số yếu tố bộ nhớ đệm, dựa trên các url hình ảnh thường gặp vào công cụ / chương trình web của bạn, vì vậy bạn cũng đang tự cứu mình ở đó.
Các hình ảnh tĩnh nhỏ (không quá vài megs) không được chỉnh sửa thường xuyên, nên được lưu trữ trong cơ sở dữ liệu. Phương pháp này có một số lợi ích bao gồm tính di động dễ dàng hơn (hình ảnh được truyền cùng với cơ sở dữ liệu), sao lưu / khôi phục dễ dàng hơn (hình ảnh được sao lưu với cơ sở dữ liệu) và khả năng mở rộng tốt hơn (một thư mục hệ thống tệp có hàng ngàn tệp thu nhỏ nghe có vẻ như một cơn ác mộng về khả năng mở rộng tôi).
Việc phục vụ hình ảnh từ cơ sở dữ liệu rất dễ dàng, chỉ cần thực hiện trình xử lý http phục vụ mảng byte được trả về từ máy chủ DB dưới dạng luồng nhị phân.
Đây là một tờ giấy trắng thú vị về chủ đề này.
Để BLOB hoặc không tới BLOB: Lưu trữ đối tượng lớn trong cơ sở dữ liệu hoặc hệ thống tệp
Câu trả lơi con phụ thuộc vao nhiêu thư." Chắc chắn nó sẽ phụ thuộc vào máy chủ cơ sở dữ liệu và cách tiếp cận của nó để lưu trữ blob. Nó cũng phụ thuộc vào loại dữ liệu được lưu trữ trong các đốm màu, cũng như cách dữ liệu đó được truy cập.
Các tệp có kích thước nhỏ hơn có thể được lưu trữ và phân phối một cách hiệu quả bằng cách sử dụng cơ sở dữ liệu làm cơ chế lưu trữ. Các tệp lớn hơn có thể sẽ được lưu trữ tốt nhất bằng hệ thống tệp, đặc biệt là nếu chúng sẽ được sửa đổi / cập nhật thường xuyên. (phân mảnh blob trở thành một vấn đề liên quan đến hiệu suất.)
Đây là một điểm bổ sung cần ghi nhớ. Một trong những lý do hỗ trợ việc sử dụng cơ sở dữ liệu để lưu trữ các đốm màu là tuân thủ ACID. Tuy nhiên, cách tiếp cận mà người kiểm tra đã sử dụng trong sách trắng, (tùy chọn Nhật ký hàng loạt của SQL Server,) đã nhân đôi thông lượng của SQL Server, đã thay đổi hiệu quả 'D' trong ACID thành 'd,' vì dữ liệu blob không được ghi lại với viết ban đầu cho giao dịch. Do đó, nếu tuân thủ ACID đầy đủ là một yêu cầu quan trọng đối với hệ thống của bạn, hãy giảm một nửa số liệu thông lượng của Máy chủ SQL để ghi cơ sở dữ liệu khi so sánh I / O của tệp với I / O của cơ sở dữ liệu.
Một điều mà tôi chưa thấy ai đề cập đến nhưng chắc chắn đáng chú ý là có những vấn đề liên quan đến việc lưu trữ một lượng lớn hình ảnh trong hầu hết các hệ thống tập tin. Ví dụ: nếu bạn sử dụng cách tiếp cận được đề cập ở trên và đặt tên cho từng tệp hình ảnh theo khóa chính, trên hầu hết các hệ thống tệp, bạn sẽ gặp vấn đề nếu bạn cố gắng đặt tất cả các hình ảnh vào một thư mục lớn khi bạn đạt được số lượng hình ảnh rất lớn ( ví dụ trong hàng trăm ngàn hoặc hàng triệu).
Một khi giải pháp chung cho việc này là băm chúng thành một cây thư mục con cân bằng.
Một cái gì đó không ai đã đề cập là DB đảm bảo các hành động nguyên tử, tính toàn vẹn giao dịch và giao dịch đồng thời. Ngay cả tính toàn vẹn tham chiếu cũng nằm ngoài cửa sổ với một hệ thống tệp - vậy làm thế nào để bạn biết tên tệp của mình thực sự vẫn đúng?
Nếu bạn có hình ảnh của mình trong một hệ thống tệp và ai đó đang đọc tệp khi bạn đang viết một phiên bản mới hoặc thậm chí xóa tệp - điều gì xảy ra?
Chúng tôi sử dụng các đốm màu vì chúng cũng dễ quản lý hơn (sao lưu, sao chép, chuyển giao). Họ làm việc tốt cho chúng tôi.
Vấn đề với việc chỉ lưu trữ các filepath vào hình ảnh trong cơ sở dữ liệu là tính toàn vẹn của cơ sở dữ liệu không còn có thể bị ép buộc.
Nếu hình ảnh thực tế được chỉ ra bởi filepath không có sẵn, cơ sở dữ liệu vô tình có lỗi toàn vẹn.
Cho rằng hình ảnh là dữ liệu thực tế đang được tìm kiếm và chúng có thể được quản lý dễ dàng hơn (hình ảnh sẽ không biến mất đột ngột) trong một cơ sở dữ liệu tích hợp thay vì phải giao tiếp với một loại hệ thống tệp (nếu hệ thống tệp được truy cập độc lập, hình ảnh MIGHT đột nhiên "biến mất"), tôi sẽ lưu trữ chúng trực tiếp dưới dạng BLOB hoặc tương tự.
Tại một công ty nơi tôi từng làm việc, chúng tôi đã lưu trữ 155 triệu hình ảnh trong cơ sở dữ liệu Oracle 8i (sau đó là 9i). Giá trị 7,5TB.
Thông thường, tôi không muốn sử dụng phần đắt nhất và khó nhất để mở rộng phần cơ sở hạ tầng của bạn (cơ sở dữ liệu) và đặt tất cả tải vào đó. Mặt khác: Nó đơn giản hóa rất nhiều chiến lược sao lưu, đặc biệt là khi bạn có nhiều máy chủ web và cần bằng cách nào đó giữ cho dữ liệu được đồng bộ hóa.
Giống như hầu hết những thứ khác, Nó phụ thuộc vào quy mô và Ngân sách dự kiến.
Chúng tôi đã triển khai một hệ thống hình ảnh tài liệu lưu trữ tất cả hình ảnh của nó trong các trường blob SQL2005. Có vài trăm GB tại thời điểm này và chúng tôi đang thấy thời gian phản hồi tuyệt vời và ít hoặc không có sự suy giảm hiệu suất. Ngoài ra, theo quy định pháp lý, chúng tôi có một lớp phần mềm trung gian lưu trữ các tài liệu mới được đăng lên một hệ thống máy hát tự động quang hiển thị chúng như một hệ thống tệp NTFS tiêu chuẩn.
Chúng tôi rất hài lòng với kết quả, đặc biệt là:
Giả định: Ứng dụng được bật web / dựa trên web
Tôi ngạc nhiên không ai thực sự đề cập đến điều này ... ủy thác nó cho những người khác là chuyên gia -> sử dụng nhà cung cấp dịch vụ lưu trữ hình ảnh / tệp của bên thứ 3 .
Lưu trữ tệp của bạn trên một dịch vụ trực tuyến phải trả tiền như
Một chủ đề StackOverflow khác nói về điều này ở đây .
Chủ đề này giải thích lý do tại sao bạn nên sử dụng nhà cung cấp dịch vụ lưu trữ bên thứ 3.
Thật đáng giá. Họ lưu trữ nó một cách hiệu quả. Không có băng thông nào được tải lên từ máy chủ của bạn tới các yêu cầu của khách hàng, v.v.
Nếu bạn không sử dụng SQL Server 2008 và bạn có một số lý do chắc chắn để đưa các tệp hình ảnh cụ thể vào cơ sở dữ liệu, thì bạn có thể sử dụng phương pháp "cả hai" và sử dụng hệ thống tệp làm bộ đệm tạm thời và sử dụng cơ sở dữ liệu làm kho lưu trữ chính .
Ví dụ: logic nghiệp vụ của bạn có thể kiểm tra xem một tệp hình ảnh có tồn tại trên đĩa hay không trước khi phục vụ nó, lấy ra từ cơ sở dữ liệu khi cần thiết. Điều này mua cho bạn khả năng của nhiều máy chủ web và ít sự cố đồng bộ hóa hơn.
Tôi không chắc có bao nhiêu ví dụ về "thế giới thực" này, nhưng hiện tại tôi có một ứng dụng lưu trữ thông tin chi tiết cho một trò chơi thẻ giao dịch, bao gồm cả hình ảnh cho các thẻ. Cho đến nay, số lượng bản ghi cho cơ sở dữ liệu chỉ là 2851 bản ghi, nhưng thực tế là một số thẻ đã được phát hành nhiều lần và có tác phẩm nghệ thuật thay thế, thực sự hiệu quả hơn là quét "hình vuông chính" của tác phẩm nghệ thuật và sau đó tự động tạo đường viền và hiệu ứng linh tinh cho thẻ khi được yêu cầu.
Người tạo ban đầu của thư viện hình ảnh này đã tạo ra một lớp truy cập dữ liệu kết xuất hình ảnh dựa trên yêu cầu và nó thực hiện khá nhanh để xem và từng thẻ riêng lẻ.
Điều này cũng giúp giảm bớt việc triển khai / cập nhật khi thẻ mới được phát hành, thay vì nén toàn bộ thư mục hình ảnh và gửi chúng xuống đường ống và đảm bảo cấu trúc thư mục phù hợp được tạo, tôi chỉ cần cập nhật cơ sở dữ liệu và yêu cầu người dùng tải xuống lại. Điều này hiện có kích thước lên tới 56MB, không phải là tuyệt vời, nhưng tôi đang làm việc trên một tính năng cập nhật gia tăng cho các bản phát hành trong tương lai. Ngoài ra, có một phiên bản "không có hình ảnh" của ứng dụng cho phép những người qua quay số có được ứng dụng mà không bị trì hoãn tải xuống.
Giải pháp này đã hoạt động rất tốt cho đến nay vì bản thân ứng dụng được nhắm mục tiêu như một phiên bản duy nhất trên máy tính để bàn. Có một trang web nơi tất cả các dữ liệu này được lưu trữ để truy cập trực tuyến, nhưng tôi sẽ không sử dụng cùng một giải pháp cho việc này. Tôi đồng ý truy cập tệp sẽ thích hợp hơn vì nó sẽ mở rộng tốt hơn theo tần suất và khối lượng yêu cầu được thực hiện cho hình ảnh.
Hy vọng rằng điều này không quá lảm nhảm, nhưng tôi đã thấy chủ đề này và muốn cung cấp một số hiểu biết của tôi về một ứng dụng quy mô nhỏ / vừa tương đối thành công.
SQL Server 2008 cung cấp một giải pháp tốt nhất của cả hai thế giới: Kiểu dữ liệu filestream .
Quản lý nó như một bảng thông thường và có hiệu suất của hệ thống tệp.
Nó phụ thuộc vào số lượng hình ảnh bạn sẽ lưu trữ và kích thước của chúng. Tôi đã sử dụng cơ sở dữ liệu để lưu trữ hình ảnh trong quá khứ và kinh nghiệm của tôi khá tốt.
IMO, Ưu điểm của việc sử dụng cơ sở dữ liệu để lưu trữ hình ảnh là,
A. Bạn không cần cấu trúc FS để giữ hình ảnh của mình
B. Chỉ mục cơ sở dữ liệu hoạt động tốt hơn cây FS khi số lượng mục được lưu trữ nhiều hơn
C. Cơ sở dữ liệu được điều chỉnh thông minh thực hiện công việc tốt khi lưu kết quả truy vấn
D. Sao lưu đơn giản. Nó cũng hoạt động tốt nếu bạn đã thiết lập sao chép và nội dung được gửi từ một máy chủ gần người dùng. Trong những trường hợp như vậy, không cần đồng bộ hóa rõ ràng.
Nếu hình ảnh của bạn sẽ nhỏ (giả sử <64k) và công cụ lưu trữ của db của bạn hỗ trợ BLOB nội tuyến (trong bản ghi), nó sẽ cải thiện hiệu suất hơn nữa vì không cần phải có hướng dẫn (Địa phương tham chiếu).
Lưu trữ hình ảnh có thể là một ý tưởng tồi khi bạn đang xử lý một số lượng nhỏ hình ảnh có kích thước khổng lồ. Một vấn đề khác với việc lưu trữ hình ảnh trong db là, siêu dữ liệu như tạo, ngày sửa đổi phải được xử lý bởi ứng dụng của bạn.
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:
Nhược điểm:
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.
Theo kinh nghiệm của tôi, tôi đã phải quản lý cả hai tình huống: hình ảnh được lưu trữ trong cơ sở dữ liệu và hình ảnh trên hệ thống tệp với đường dẫn được lưu trữ trong db.
Giải pháp đầu tiên, hình ảnh trong cơ sở dữ liệu, có phần "sạch" hơn vì lớp truy cập dữ liệu của bạn sẽ chỉ phải xử lý các đối tượng cơ sở dữ liệu; nhưng điều này chỉ tốt khi bạn phải đối phó với số lượng thấp.
Rõ ràng hiệu suất truy cập cơ sở dữ liệu khi bạn xử lý các đối tượng lớn nhị phân đang xuống cấp và kích thước cơ sở dữ liệu sẽ tăng lên rất nhiều, gây mất hiệu suất một lần nữa ... và thông thường không gian cơ sở dữ liệu đắt hơn nhiều so với không gian hệ thống tệp.
Mặt khác, việc có các đối tượng nhị phân lớn được lưu trữ trong hệ thống tệp sẽ khiến bạn có các gói sao lưu phải xem xét cả cơ sở dữ liệu và hệ thống tệp và đây có thể là một vấn đề đối với một số hệ thống.
Một lý do khác để sử dụng hệ thống tệp là khi bạn phải chia sẻ dữ liệu hình ảnh của mình (hoặc âm thanh, video, bất cứ thứ gì) với quyền truy cập của bên thứ ba: trong thời đại này, tôi đang phát triển một ứng dụng web sử dụng hình ảnh phải được truy cập từ "bên ngoài "Trang trại web của tôi theo cách mà cơ sở dữ liệu truy cập để lấy dữ liệu nhị phân đơn giản là không thể. Vì vậy, đôi khi cũng có những cân nhắc thiết kế sẽ đưa bạn đến một sự lựa chọn.
Cũng xem xét, khi đưa ra lựa chọn này, nếu bạn phải đối phó với sự cho phép và xác thực khi truy cập các đối tượng nhị phân: những điều cần thiết này thường có thể được giải quyết theo cách dễ dàng hơn khi dữ liệu được lưu trữ trong db.
Tôi đã từng làm việc trên một ứng dụng xử lý hình ảnh. Chúng tôi đã lưu trữ các hình ảnh được tải lên trong một thư mục giống như / hình ảnh / [ngày hôm nay] / [số id]. Nhưng chúng tôi cũng trích xuất siêu dữ liệu (dữ liệu exif) từ hình ảnh và lưu trữ trong cơ sở dữ liệu, cùng với dấu thời gian và như vậy.
Trong một dự án trước đây, tôi đã lưu trữ hình ảnh trên hệ thống tập tin và điều đó gây ra rất nhiều vấn đề đau đầu với các bản sao lưu, sao chép và hệ thống tập tin không đồng bộ với cơ sở dữ liệu.
Trong dự án mới nhất của tôi, tôi đang lưu trữ hình ảnh trong cơ sở dữ liệu và lưu trữ chúng trên hệ thống tập tin và nó hoạt động rất tốt. Tôi đã không có vấn đề cho đến nay.
Thứ hai khuyến nghị về đường dẫn tập tin. Tôi đã làm việc với một vài dự án cần thiết để quản lý các bộ sưu tập tài sản lớn và bất kỳ nỗ lực nào để lưu trữ mọi thứ trực tiếp trong DB đều dẫn đến đau đớn và thất vọng về lâu dài.
"Pro" thực sự duy nhất tôi có thể nghĩ đến về việc lưu trữ chúng trong DB là khả năng dễ dàng cho các tài sản hình ảnh riêng lẻ. Nếu không có đường dẫn tệp nào để sử dụng và tất cả các hình ảnh được truyền thẳng ra khỏi DB, sẽ không có nguy cơ người dùng tìm thấy các tệp mà họ không nên truy cập.
Điều đó có vẻ như sẽ được giải quyết tốt hơn với một tập lệnh trung gian lấy dữ liệu từ kho lưu trữ tệp không thể truy cập web. Vì vậy, bộ lưu trữ DB không thực sự cần thiết.
Từ trên đường phố là trừ khi bạn là nhà cung cấp cơ sở dữ liệu cố gắng chứng minh rằng cơ sở dữ liệu của bạn có thể làm điều đó (như giả sử Microsoft khoe khoang về Terraserver lưu trữ một hình ảnh bajillion trong SQL Server) thì đó không phải là ý kiến hay. Khi thay thế - lưu trữ hình ảnh trên máy chủ tệp và đường dẫn trong cơ sở dữ liệu dễ dàng hơn nhiều, tại sao phải bận tâm? Các lĩnh vực Blob giống như khả năng off-road của SUV - hầu hết mọi người không sử dụng chúng, những người thường gặp rắc rối, và sau đó có những người làm, nhưng chỉ vì niềm vui của nó.
Lưu trữ một hình ảnh trong cơ sở dữ liệu vẫn có nghĩa là dữ liệu hình ảnh kết thúc ở đâu đó trong hệ thống tệp nhưng bị che khuất để bạn không thể truy cập trực tiếp vào nó.
+ ves:
-ves:
Cả hai phương pháp đều phổ biến và được thực hành. Có một cái nhìn về những lợi thế và bất lợi. Dù bằng cách nào, bạn sẽ phải suy nghĩ về cách khắc phục nhược điểm. Lưu trữ trong cơ sở dữ liệu thường có nghĩa là điều chỉnh các tham số cơ sở dữ liệu và thực hiện một số loại bộ đệm. Sử dụng hệ thống tập tin đòi hỏi bạn phải tìm cách đồng bộ hóa cơ sở dữ liệu + hệ thống tập tin.