Lưu trữ hàng triệu tệp nhật ký - Khoảng 25 TB mỗi năm

Question

Là một phần công việc của tôi, chúng tôi nhận được tệp nhật ký trị giá khoảng 25TB mỗi năm, hiện được lưu trên hệ thống tệp dựa trên NFS. Một số được lưu trữ như trong nén/tar.gz trong khi những người khác cư trú ở định dạng văn bản thuần túy.

Tôi đang tìm các giải pháp thay thế bằng cách sử dụng hệ thống dựa trên NFS. Tôi nhìn MongoDB, CouchDB. Thực tế là chúng là cơ sở dữ liệu định hướng tài liệu dường như làm cho nó phù hợp. Tuy nhiên, nội dung tệp nhật ký cần được thay đổi thành JSON để được lưu trữ trong DB. Một cái gì đó tôi không sẵn sàng để làm. Tôi cần giữ lại nội dung tệp nhật ký.

Về cách sử dụng, chúng tôi dự định đặt một API REST nhỏ và cho phép mọi người lấy danh sách tệp, tệp mới nhất và khả năng tải tệp. Các giải pháp/ý tưởng được đề xuất cần phải là một dạng cơ sở dữ liệu hoặc hệ thống tệp được phân tán ở cấp ứng dụng, nơi có thể lưu trữ tệp nhật ký và có thể mở rộng theo chiều ngang hiệu quả bằng cách thêm nhiều máy hơn.

Ankur

Answer 1

Hãy xem Vertica, một cơ sở dữ liệu cột hỗ trợ xử lý song song và các truy vấn nhanh. Comcast đã sử dụng nó để analyze about 15GB/day of SNMP data, chạy với tốc độ trung bình 46.000 mẫu mỗi giây, sử dụng năm máy chủ HP Proliant lõi tứ. Tôi nghe một số hoạt động Comcast folks rave về Vertica một vài tuần trước đây; họ vẫn thực sự thích nó. Nó có một số kỹ thuật nén dữ liệu tốt đẹp và "dự phòng an toàn k", vì vậy họ có thể phân phối với một SAN.

Cập nhật: Một trong những lợi thế chính của phương pháp tiếp cận cơ sở dữ liệu phân tích có thể mở rộng là bạn có thể thực hiện một số truy vấn thời gian thực phức tạp, gần như thực tế của nhật ký. Điều này có thể thực sự có giá trị cho nhóm ops của bạn.

Answer 2

Vì bạn không muốn các tính năng queriying, Bạn có thể sử dụng apache hadoop.

Tôi tin HDFS và HBase sẽ phù hợp với điều này.

Bạn có thể thấy rất nhiều câu chuyện lưu trữ khổng lồ bên trong Hadoop powered by trang

Answer 3

Bạn đã cố gắng nhìn vào gluster? Nó có thể mở rộng, cung cấp bản sao và nhiều tính năng khác. Nó cũng cung cấp cho bạn các hoạt động tệp chuẩn nên không cần triển khai một lớp API khác.

http://www.gluster.org/

Answer 4

tôi sẽ mạnh mẽ disrecommend sử dụng một chìa khóa/giá trị hoặc tài liệu lưu trữ dựa cho dữ liệu này (Mongo, cassandra, vv). Sử dụng hệ thống tệp. Điều này là do các tệp quá lớn và mẫu truy cập sẽ là quét tuyến tính. Một vấn đề mà bạn sẽ gặp phải là lưu giữ. Hầu hết các hệ thống lưu trữ "NoSQL" sử dụng xóa hợp lý, có nghĩa là bạn phải nén cơ sở dữ liệu của mình để xóa các hàng đã xóa. Bạn cũng sẽ có một vấn đề nếu hồ sơ đăng nhập cá nhân của bạn là nhỏ và bạn phải lập chỉ mục mỗi một trong số họ - chỉ mục của bạn sẽ rất lớn.

Đặt dữ liệu của bạn ở chế độ HDFS bằng cách nhân bản 2-3 cách trong khối 64 MB theo cùng định dạng mà hiện tại đang có.

Answer 5

Nếu bạn đang lựa chọn một cơ sở dữ liệu tài liệu:

On CouchDB bạn có thể sử dụng API _attachement để đính kèm tập tin như là một tài liệu, tài liệu bản thân có thể chỉ chứa siêu dữ liệu (như dấu thời gian, địa bàn và vv) để lập chỉ mục. Sau đó, bạn sẽ có một API REST cho các tài liệu và các phần đính kèm.

Một phương pháp tương tự cũng có thể thực hiện với GridF của Mongo, nhưng bạn sẽ tự xây dựng API.

Ngoài ra HDFS là một lựa chọn rất hay.