2011-07-04 4 views
9

Tôi tương đối mới với cơ sở dữ liệu NoSQL và tôi phải đánh giá các giải pháp NoSQL khác nhau cho một công cụ giám sát.CouchDB có thể xử lý 15 triệu bản ghi hàng ngày không?

Tình huống như sau: Một mốc dữ liệu chỉ khoảng 100 byte lớn, nhưng thực sự có rất nhiều dữ liệu. Trong một ngày, chúng tôi có khoảng 15 triệu bản ghi ... Vì vậy, tôi hiện đang thử nghiệm với 900 triệu bản ghi (khoảng 15 GB dưới dạng Tập lệnh Chèn SQL)

Câu hỏi của tôi là: Couchdb có phù hợp với nhu cầu của tôi không? Tôi cần phải làm các truy vấn phạm vi (vào ngày các hồ sơ được tạo ra) và tổng hợp một số cột theo các nhóm được xác định bởi "chỉ số phụ" được lưu trữ trong mốc.) Tôi biết rằng MapReduce có lẽ là giải pháp tốt nhất để tính toán , nhưng là JavaScript của CouchDB có thể làm điều này trong một thời gian chấp nhận được?

Tôi đã thử MongoDB nhưng nó thực sự nghèo MapReduce đã thực hiện một công việc crappy ... Tôi cũng đọc về HBase và Cassandra. Nhưng maybee CouchDB cũng là một khả năng tốt

Tôi hy vọng tôi đã cung cấp cho bạn tất cả các thông tin cần thiết ... Cảm ơn sự giúp đỡ của bạn!

andy

+1

Đầu tiên, cách duy nhất để biết hiệu suất là đo lường vì có quá nhiều biến để đoán. Thứ hai, không quá hấp dẫn để lưu trữ được lưu trữ khi một nửa thế kỷ kinh nghiệm RDBM đang chờ xử lý dữ liệu 100 octet của bạn. Tôi đoán tại 100B/hàng, dữ liệu của bạn không phải là rất biến thể (nơi SS trội). – msw

+0

Điểm tốt, @msw. Tất nhiên, cách để * definitively * biết hiệu suất là đo lường; tuy nhiên tôi cho rằng nó là hợp lệ để yêu cầu ước tính ước tính đầu tiên, ước tính của ballpark. Tôi đã sửa đổi tiêu đề câu hỏi thành màu đen và trắng hơn một chút. (Không chắc chắn nếu bạn bỏ phiếu để đóng hoặc đó là một người nào khác, nhưng IMHO nó là một câu hỏi công bằng.) Cuối cùng, hoàn toàn đúng về RDBM. Chúng có giá trị hơn chúng ta cho tín dụng. – JasonSmith

+0

Dữ liệu tôi đang đánh giá hiện đang được xử lý bởi một SQL-Server thực sự mạnh mẽ. Nhưng nó không thể xử lý các yêu cầu mà người dùng gửi để thu thập thông tin từ khối lượng dữ liệu. Nó chỉ đơn giản là cần nhiều thời gian. Đó là lý do tại sao chúng tôi tìm kiếm NoSQL-Solutions với khả năng mở rộng theo chiều ngang. – andy

Trả lời

9

Thẳng thắn mà nói, vào thời điểm này, trừ khi bạn có phần cứng rất tốt, Apache CouchDB có thể chạy vào vấn đề. Bản đồ/giảm có thể sẽ ổn. Bản đồ/giảm của của CouchDB là lý tưởng cho các yêu cầu của bạn.

Là nhà phát triển, bạn sẽ thích nó! Thật không may là một sysadmin, bạn có thể nhận thấy sử dụng đĩa nhiều hơn và i/o hơn dự kiến.

Tôi đề nghị dùng thử. Là HTTP và Javascript, thật dễ dàng để thực hiện kiểm tra tính khả thi. Chỉ cần nhớ, việc xây dựng khung nhìn ban đầu sẽ mất một thời gian dài (chúng ta hãy giả sử đối số phải mất nhiều thời gian hơn mọi cơ sở dữ liệu cạnh tranh khác). Nhưng thời gian đó sẽ không bao giờ được chi tiêu lại. Bản đồ/giảm chạy chỉ chỉ một lần cho mỗi tài liệu (trên mỗi bản cập nhật tài liệu).

Nếu tên thương hiệu Apache CouchDB chậm, nhưng bạn thích thư giãn trên chiếc ghế dài, sau đó cụm BigCouch chắc chắn sẽ xử lý tải mà không gặp sự cố. Tôi khá chắc chắn có những cụm BigCouch với dữ liệu lớn hơn và yêu cầu i/o hơn thế này.

+1

+1 Tuy nhiên nó là công bằng để lưu ý rằng "không bao giờ" ở đây có nghĩa là "cho đến khi, một số thay đổi đối với tài liệu thiết kế kích thích một xây dựng lại của xem." Chỉ cần để giúp bạn chuẩn bị cho điều này ... :) –

+4

Để sử dụng sản xuất, có một giải pháp cho điều đó. Nếu bạn hỏi làm thế nào, tôi sẽ được vui để cung cấp thông tin chi tiết. Phiên bản ngắn: Gửi tài liệu thiết kế mới với một id khác. Truy vấn nó để xây dựng chỉ mục.Khi hoàn thành, hãy sử dụng HTTP COPY để đổi tên cái mới hơn cái cũ. Nâng cấp nguyên tử, không có thời gian chết. – JasonSmith

+0

+1 'đây là một câu hỏi công bằng và một câu trả lời công bằng (và tôi cố gắng nhẹ nhàng với các thành viên mới hơn, vì vậy không có phiếu bầu nào từ tôi mà không có lời giải thích (vì bạn đã hỏi một cách xiên)). – msw