Lưu trữ quy mô lớn cho các tài liệu được thêm vào gia tăng?

Question

Tôi cần lưu trữ hàng trăm nghìn (ngay bây giờ, có thể có hàng triệu) tài liệu bắt đầu trống và được nối vào thường xuyên, nhưng không bao giờ được cập nhật theo cách khác hoặc bị xóa. Các tài liệu này không liên quan đến nhau theo bất kỳ cách nào và chỉ cần một số ID duy nhất truy cập.

Truy cập đọc là một số tập hợp con của tài liệu, hầu như luôn bắt đầu giữa chừng tại một số vị trí được lập chỉ mục (ví dụ: "tài liệu # 4324319, lưu # 53 đến cuối").

Những tài liệu này bắt đầu rất nhỏ, ở vài KB. Họ thường đạt kích thước cuối cùng khoảng 500KB, nhưng nhiều người đạt 10MB trở lên.

Tôi hiện đang sử dụng MySQL (InnoDB) để lưu trữ các tài liệu này. Mỗi tiết kiệm gia tăng chỉ được đổ vào một bảng lớn với ID tài liệu mà nó thuộc về, vì vậy đọc một phần của tài liệu trông giống như "select * from save where document_id = 14 and save_id> 53 order by save_id", sau đó ghép nối thủ công tất cả cùng nhau trong mã.

Lý tưởng nhất, tôi muốn các giải pháp lưu trữ được dễ dàng theo chiều ngang mở rộng, với sự dư thừa trên máy chủ (ví dụ mỗi tài liệu được lưu trữ trên ít nhất 3 nút) với phục hồi dễ dàng của máy chủ bị rơi.

Tôi đã xem xét CouchDB và MongoDB là có thể thay thế cho MySQL, nhưng tôi không chắc chắn rằng một trong hai cách này có ý nghĩa rất lớn cho ứng dụng cụ thể này, mặc dù tôi đang cởi mở để được thuyết phục.

Bất kỳ đầu vào nào trên một giải pháp lưu trữ tốt?

Answer 1

Âm thanh như một vấn đề lý tưởng cần được giải quyết bằng HBase (Hơn HDFS).

Nhược điểm là đường cong học tập hơi dốc, trong số những trường hợp khác.

Answer 2

Có lý do nào bạn cần một cơ sở dữ liệu không?

Bạn mô tả "hệ thống lưu trữ tài liệu có tên duy nhất" nên tôi bắt đầu nghĩ "hệ thống tệp". Có lẽ một cái gì đó giống như máy chủ tập tin lớp doanh nghiệp/s (tôi ước tính tối đa khoảng 200 TiB dữ liệu), trong đó ID duy nhất là một tên thư mục và tập tin trên mạng.

Answer 3

Suy nghĩ tức thì của tôi là lý do tại sao lưu trữ chúng trong cơ sở dữ liệu? Việc lưu trữ chúng trong một kết quả cơ sở dữ liệu có hiệu suất tìm kiếm tốt hơn so với một hệ thống tập tin khi xử lý rất nhiều tệp không?

Tôi nghĩ rằng việc lưu trữ các tệp này trên một hệ thống tệp trong cấu trúc thư mục được băm sẽ tốt hơn. Bạn có thể sử dụng cơ sở dữ liệu để lưu trữ chỉ dữ liệu meta (thư mục gốc, id tài liệu, lưu id, vị trí tương đối so với gốc).

Thư mục gốc (nút) sẽ là một bảng riêng biệt và có thể được sử dụng khi viết (liệt kê và ghi vào tất cả các vị trí) và sau đó xoay vòng (hoặc thuật toán cân bằng tải) khác để đọc.

Nếu nút không thể truy cập được hoặc tệp không tồn tại, cân bằng tải có thể "không thành công" cho dòng tiếp theo trong dòng. Thư mục gốc cũng có thể được đánh dấu ngoại tuyến cho các cúp đã lên kế hoạch nếu mã đọc/ghi tôn trọng điều đó. Điều tương tự cũng có thể được sử dụng để phân vùng nơi x số lượng thư mục gốc phục vụ số lẻ và số x phục vụ ngay cả id là một ví dụ đơn giản.

Đảm bảo các nút được đồng bộ hóa có thể được mã hóa bằng cách sử dụng dữ liệu meta.

Chỉ 2 xu của tôi vì tôi chưa bao giờ xử lý khối lượng tệp đó trước đây.

Answer 4

OK, trước tiên hãy báo trước, MongoDB không có giới hạn về kích thước tài liệu. Tuy nhiên, phiên bản mới nhất sẽ bao gồm kích thước 10MB của bạn.

Vì vậy, một số điểm hữu ích cho MongoDB.

Lý tưởng nhất, tôi muốn giải pháp lưu trữ dễ dàng mở rộng theo chiều ngang, với dự phòng trên các máy chủ (ví dụ: mỗi tài liệu được lưu trữ trên ít nhất 3 nút) với sự phục hồi dễ dàng của máy chủ bị lỗi.

Để nhân rộng, MongoDB hỗ trợ replica sets. Bản sao bộ là bản sao đơn chủ. Nếu tổng thể đi xuống hệ thống sẽ tự động chọn một tổng thể mới (phục hồi dễ dàng). Thêm một nút mới đơn giản như khởi động một máy chủ mới và chỉ vào tập hợp hiện có.

Đối với khả năng mở rộng ngang, MongoDB hỗ trợ sharding. Sharding phức tạp hơn một chút, nhưng hoạt động giống như bạn mong đợi nó, chia tách viết trên nhiều máy (hoặc nhiều bộ bản sao).

tôi cần phải lưu trữ hàng trăm ngàn (ngay bây giờ, có khả năng nhiều triệu) của tài liệu mà bắt đầu rỗng và được nối vào thường xuyên

Một số công ty đã Mongo chạy tỷ tài liệu trong sản xuất.

Mongo cung cấp một loạt các update modifiers rất hữu ích trong trường hợp "được thêm vào". Đặc biệt, hãy kiểm tra toán tử đẩy $ để thêm vào cuối mảng. Nên chính xác những gì bạn cần.

Truy cập đọc là một số tập hợp con của tài liệu, hầu như luôn bắt đầu giữa chừng tại một số vị trí được lập chỉ mục (ví dụ: "tài liệu # 4324319, lưu # 53 đến cuối").

MongoDB cho phép bạn chỉ trả về các trường được chọn (như mong đợi). Tùy thuộc vào bố cục của bạn, bạn có thể sử dụng dot notation để chỉ truy xuất một số tài liệu phụ nhất định. Nếu bản cập nhật của bạn được triển khai dưới dạng mảng, bạn cũng có thể sử dụng số $slice command phù hợp với truy vấn bạn liệt kê ở trên.

Vì vậy, tôi nghĩ MongoDB đáp ứng tất cả các nhu cầu cơ bản của bạn ở đây. Dễ dàng nối thêm, dễ dàng truy vấn các phần bổ sung đó và bản sao được tích hợp. Bạn có thể mở rộng theo chiều ngang thông qua sharding (thử bắt đầu với bản sao)

Answer 5

Kiểm tra hệ thống tệp ảo SolFS của chúng tôi. Nó sẽ hoạt động tốt trong điều kiện của bạn.