2011-12-02 25 views
7

Tôi đang tìm một nơi lý tưởng (hiệu suất và duy trì) để lưu trữ dữ liệu nhị phân. Trong trường hợp của tôi, đây là những hình ảnh. Tôi phải thực hiện một số xử lý ảnh, chia tỷ lệ hình ảnh và lưu trữ ở một nơi phù hợp có thể truy cập thông qua dịch vụ RESTful.Nơi lý tưởng để lưu trữ dữ liệu nhị phân có thể được hiển thị bằng cách gọi url

Từ nghiên cứu của tôi cho đến nay tôi có một vài lựa chọn, như:

  1. NoSQL giải pháp như MongoDB, GridFS
  2. lưu trữ dưới dạng file trong một hệ thống tập tin trong một hệ thống phân cấp thư mục và sau đó sử dụng một máy chủ web để truy cập hình ảnh bằng cách url
  3. kho
  4. Apache Jackrabbit Document
  5. Store trong một cái gì đó bộ nhớ cache như Memcache, Squid Proxy

Bất kỳ ý tưởng nào về việc bạn sẽ chọn cái nào và tại sao lại hữu ích hoặc có cách nào tốt hơn để làm điều đó?

Trả lời

1

Lưu trữ các hình ảnh như đốm màu trong một RDBMS trong tùy chọn khác, và bạn ngay lập tức nhận được một số đảm bảo về tính toàn vẹn, bảo mật vv (nếu điều này được thiết lập đúng trên cơ sở dữ liệu), lưu trữ thêm siêu dữ liệu, quản lý bộ sưu tập với SQL, vv

+1

Cần lưu ý rằng trong các ứng dụng có khối lượng tệp được đưa vào hệ thống rất cao, đây không phải lúc nào cũng là một tùy chọn. Các đốm màu được lưu trữ dưới dạng tập tin đầy đủ và không được chunked, do đó, các giá trị hàng có thể nhận được thực sự lớn và làm cho DB sao lưu theo cấp số nhân lớn hơn. Một trong những nên luôn luôn xem xét nhân rộng cân nhắc và khối lượng đầu vào trước khi đi với tùy chọn này. – DeaconDesperado

7

Chỉ mới bắt đầu sử dụng GridFS để thực hiện chính xác những gì bạn mô tả.

Từ kinh nghiệm của tôi cho đến nay, lợi thế chính của GridFS là nó giảm bớt sự cần thiết cho một hệ thống lưu trữ tệp riêng biệt. Toàn bộ lớp persistency của chúng ta đã được đưa vào Mongo, và vì vậy bước hợp lý tiếp theo sẽ là lưu trữ hệ thống tập tin của chúng ta ở đó. Các căn hộ không gian tên chỉ đá và cho phép bạn một ngôn ngữ truy vấn phong phú để lấy các tập tin của bạn dựa trên bất cứ điều gì siêu dữ liệu bạn muốn đính kèm vào chúng. Trong ứng dụng của chúng tôi, chúng tôi đã sử dụng đối tượng 'appdata' để nhúng tất cả thông tin về quyền sở hữu, đảm bảo

Một điều cần xem xét với lưu trữ tệp NoSQL và đặc biệt là GridFS, là nó sẽ phân chia và mở rộng cùng với dữ liệu khác của bạn. Nếu bạn đã có toàn bộ kho khóa-giá trị DB bên trong máy chủ mongo, thì cuối cùng nếu bạn phải mở rộng cụm máy chủ của mình với nhiều máy hơn, hệ thống tệp của bạn sẽ phát triển cùng với nó.

Nó có thể cảm thấy một 'hộp đen' nhỏ vì dữ liệu nhị phân được chia thành nhiều phần, một viễn cảnh làm cho những người sử dụng hệ thống tập tin dựa trên thư mục kinh điển sợ hãi. Điều này được giảm bớt với sự trợ giúp của các chương trình quản trị như RockMongo.

Tất cả trong tất cả để lưu trữ hình ảnh trong GridFS dễ dàng như chèn tài liệu, hầu hết các trình điều khiển cho tất cả các ngôn ngữ chính xử lý mọi thứ cho bạn. Trong môi trường của chúng tôi, chúng tôi đã tải lên hình ảnh tại điểm cuối và sử dụng PIL để thực hiện thay đổi kích thước. Các hình ảnh sau đó được lấy từ mongo tại một điểm cuối khác mà chỉ xuất dữ liệu và bắt chước nó dưới dạng jpeg.

Chúc bạn may mắn!

EDIT:

Để cung cấp cho bạn một ví dụ của một tập tin tầm thường tải lên với GridFS, đây là phương pháp đơn giản nhất trong PyMongo, thư viện python.

from pymongo import Connection 
import gridfs 

binary_data = 'Hello, world!' 

db = Connection().test_db 
fs = gridfs.GridFS(db) 
#the filename kwarg sets the filename in the mongo doc, but you can pass anything in 
#and make custom key-values too. 
file_id = fs.put(binary_data, filename='helloworld.txt',anykey="foo") 
output = fs.get(file_id).read() 
print output 
>>>Hello, world! 

Bạn cũng có thể truy vấn giá trị tùy chỉnh nếu muốn, điều này có thể hữu ích nếu bạn muốn truy vấn dựa trên thông tin tùy chỉnh liên quan đến ứng dụng của bạn.

try: 
    file = fs.get_last_version({'anykey':'foo'}) 
    return file.read() 
catch gridfs.errors.NoFile: 
    return None 

Đây chỉ là một số ví dụ đơn giản và trình điều khiển cho nhiều ngôn ngữ khác (PHP, Ruby, v.v.) đều có cùng nguồn gốc.

+0

Cảm ơn bạn đã chia sẻ, thực sự đánh giá cao nó. Bạn có nghĩ rằng đọc từ đĩa I/O là đắt hơn hoặc chỉ có tất cả các dữ liệu ở một nơi là lý do để có nó trong mogo và làm thế nào là nó thực hiện cho đến nay? – dineshr

+0

Thời gian tệp IO không thực sự ảnh hưởng đến quyết định của chúng tôi, mặc dù để tham khảo thời gian tìm nạp có thể so sánh với truy vấn được lập chỉ mục chuẩn trong sql. Kể từ khi khối lượng của các tập tin là rất cao các điểm tham quan của việc có một không gian tên lớn có thể được sharded theo chiều ngang là lý do chính. Sử dụng GridFS làm cho nó để cấu trúc thư mục không còn là một vấn đề, và các tập tin của bạn có thể được lấy và chèn bằng cách sử dụng các trình điều khiển API. Nó làm việc tuyệt vời trong một ứng dụng RESTful nơi mà các yêu cầu url xác định phản ứng. – DeaconDesperado

3

tôi sẽ đi cho con thỏ rừng kết hợp với REST khuôn khổ sling của nó http://sling.apache.org

Sling cho phép bạn tải lên/tải các tập tin thông qua REST của cuộc gọi hoặc WebDAV trong khi kho con thỏ rừng cơ bản cung cấp cho bạn một kho performant với khả năng lưu trữ của bạn tập tin trong một cấu trúc cây (hoặc bằng phẳng nếu bạn thích).

Cả hai jackrabbit và sling đều hỗ trợ cơ chế sự kiện nơi bạn có thể xử lý ảnh không đồng bộ sau khi tải lên, tức là tạo hình thu nhỏ.

Hướng dẫn tại http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html mô tả cách thao tác dữ liệu bằng giao diện REST được cung cấp bởi sling.

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