Tôi phát triển một trang web mới và tôi muốn sử dụng GridFS làm bộ nhớ cho tất cả các tệp tải lên của người dùng, bởi vì nó mang lại rất nhiều lợi thế so với bộ lưu trữ hệ thống tệp thông thường.
Các điểm chuẩn với GridFS do nginx cung cấp cho thấy rằng nó không nhanh như một hệ thống tệp bình thường do nginx cung cấp.
Có ai ở ngoài đó, những người sử dụng GridFS đã có trong môi trường sản xuất, hoặc sẽ sử dụng nó cho một dự án mới không?
Câu trả lời:
Tôi sử dụng gridfs tại nơi làm việc trên một trong những máy chủ của chúng tôi, một phần của trang web so sánh giá với số liệu thống kê về lưu lượng truy cập đáng nể (khoảng 25 nghìn khách truy cập mỗi ngày). Máy chủ không có nhiều ram, 2gigs và thậm chí là cpu không thực sự nhanh (Core 2 duo 1.8Ghz) nhưng máy chủ có nhiều dung lượng lưu trữ: 10Tb (sata) trong cấu hình đột kích 0. Công việc mà máy chủ đang làm rất đơn giản:
Mỗi sản phẩm trên công cụ so sánh giá của chúng tôi đều có một hình ảnh (có khoảng 10 triệu sản phẩm theo db sản phẩm của chúng tôi) và công việc của máy chủ là tải hình ảnh xuống, thay đổi kích thước, lưu trữ hình ảnh trên gridfs và cung cấp cho trình duyệt của khách truy cập. .. nếu nó không có trong lưới ... hoặc ... gửi nó đến trình duyệt của khách truy cập nếu nó đã được lưu trong lưới. Vì vậy, đây có thể được gọi là 'lược đồ cdn truyền thống'.
Chúng tôi đã lưu trữ và xử lý 4 triệu hình ảnh trên máy chủ này kể từ khi nó hoạt động. Việc thay đổi kích thước và lưu trữ nội dung được thực hiện bằng một tập lệnh php đơn giản ... nhưng chắc chắn, một tập lệnh python hoặc thứ gì đó như java có thể nhanh hơn.
Kích thước dữ liệu hiện tại: 11,23g
Kích thước lưu trữ hiện tại: 12,5g
Chỉ số: 5
Kích thước chỉ số: 849,65m
Về độ tin cậy: Điều này rất đáng tin cậy. Máy chủ không tải, kích thước chỉ mục ổn, truy vấn nhanh
Về tốc độ: Chắc chắn, nó không nhanh bằng lưu trữ tệp cục bộ, có thể chậm hơn 10%, nhưng đủ nhanh để sử dụng trong thời gian thực ngay cả khi hình ảnh cần được xử lý, điều này phụ thuộc vào php trong trường hợp của chúng tôi. Thời gian bảo trì và phát triển cũng được giảm bớt: việc xóa một hoặc nhiều hình ảnh trở nên đơn giản: chỉ cần truy vấn db bằng một lệnh xóa đơn giản. Một điều thú vị khác: khi chúng tôi khởi động lại máy chủ cũ, với bộ lưu trữ tệp cục bộ (hàng triệu tệp trong hàng nghìn thư mục), đôi khi nó bị treo hàng giờ khiến hệ thống đang thực hiện kiểm tra tính toàn vẹn của tệp (việc này thực sự mất hàng giờ đồng hồ ...). Chúng tôi không gặp vấn đề này nữa với gridfs, hình ảnh của chúng tôi hiện được lưu trữ trong các khối mongodb lớn (tệp 2gb)
Vì vậy ... theo suy nghĩ của tôi ... Vâng, gridfs đủ nhanh và đáng tin cậy để được sử dụng cho sản xuất.
Như đã đề cập, nó có thể không nhanh như một hệ thống tệp thông thường nhưng sau đó nó mang lại cho bạn lợi thế so với các hệ thống tệp thông thường mà tôi nghĩ đáng để bỏ ra một chút tốc độ.
Cuối cùng, với sharding, tuy nhiên, bạn có thể đạt đến điểm mà bộ lưu trữ GridFS thực sự trở thành tùy chọn nhanh hơn so với hệ thống tệp thông thường và một nút duy nhất.
Mặc dù vậy, hãy lưu ý về việc sửa chữa cho các DB lớn hơn - một hệ thống mới mà chúng tôi đang phát triển, mongo đã không thoát sạch và việc sửa chữa GridFS 7TB có vẻ như sẽ mất 130 giờ.
Vì lý do này, tôi nghĩ tôi sẽ xem xét việc chuyển sang OpenStack Swift hoặc Ceph. Tuy nhiên, cho đến lúc đó thì tốt. Và mô-đun nginx-gridfs rất thú vị.
Tôi không khuyên bạn nên sử dụng gridfs trừ khi bạn biết mình đang làm gì. GridFS chỉ là lớp trừu tượng chia các tệp thành nhiều phần và lưu trữ tệp trong hai bộ sưu tập. Nhiều tệp hơn - nhiều chi phí hơn. Nếu bạn mong đợi các tệp có cùng kích thước, không vượt quá 32M hoặc lâu hơn - bạn đang làm đúng. Đừng cố gắng lưu trữ các tệp lớn trên gridfs. Tại sao?
Nếu bạn nghĩ về dự án đã tải đã đọc - hãy xem xét tải trực tiếp các tệp vào tài liệu (nếu kích thước 16M trở xuống) hoặc chọn một clusterfs khác và liên kết tên tệp / inode với logic của bạn.
Hi vọng điêu nay co ich.