Xử lý dữ liệu có quy mô lớn Hbase vs Cassandra

Question

Tôi gần như đã hạ cánh tại Cassandra sau khi nghiên cứu về các giải pháp lưu trữ dữ liệu quy mô lớn. Nhưng nói chung, Hbase là giải pháp tốt hơn để xử lý và phân tích dữ liệu quy mô lớn.

Mặc dù cả hai đều là cùng một lưu trữ khóa/giá trị và cả hai đều có thể chạy (Cassandra gần đây) Lớp Hadoop sau đó điều khiến Hadoop trở thành ứng cử viên tốt hơn khi xử lý/phân tích được yêu cầu trên dữ liệu lớn.

Tôi cũng thấy chi tiết tốt về cả ở http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

nhưng tôi vẫn đang tìm kiếm lợi thế cụ thể của HBase.

Trong khi tôi tin chắc hơn về Cassandra vì tính đơn giản của nó cho việc thêm nút và sao chép liền mạch và không có điểm của các tính năng thất bại. Và nó cũng giữ tính năng chỉ số phụ để một cộng thêm của nó.

Answer 1

Cố gắng xác định xem điều gì là tốt nhất cho bạn thực sự phụ thuộc vào những gì bạn định sử dụng, chúng có lợi thế và không có thêm chi tiết nào để trở thành chiến tranh tôn giáo. Bài đăng đó mà bạn tham chiếu cũng đã hơn một năm và cả hai đã trải qua nhiều thay đổi kể từ đó. Cũng xin lưu ý rằng tôi không quen thuộc với những phát triển Cassandra gần đây.

Có nói rằng, tôi sẽ diễn giải HBase committer Andrew Purtell và thêm một số kinh nghiệm của riêng tôi:

• HBase là trong môi trường sản xuất lớn (1000 nodes) mặc dù đó vẫn còn trong sân chơi bóng chày của Cassandra của ~ 400 lượt cài đặt nút để sự khác biệt thực sự của nó.

• Cả HBase và Cassandra đều hỗ trợ sao chép giữa các cụm/trung tâm dữ liệu. Tôi tin rằng HBase sẽ tiết lộ nhiều hơn cho người dùng để nó xuất hiện phức tạp hơn nhưng sau đó bạn cũng sẽ linh hoạt hơn.

• Nếu tính nhất quán cao là những gì ứng dụng của bạn cần thì HBase có thể phù hợp hơn. Nó được thiết kế từ mặt đất lên để phù hợp. Ví dụ, nó cho phép thực hiện đơn giản hơn các bộ đếm nguyên tử (tôi nghĩ Cassandra vừa nhận được chúng) cũng như các hoạt động Kiểm tra và Đặt.

• Viết hiệu suất thật tuyệt vời, từ những gì tôi hiểu đó là một trong những lý do Facebook đi cùng HBase cho sứ giả của họ.

• Tôi không chắc chắn về trạng thái hiện tại của trình phân vùng được sắp xếp của Cassandra, nhưng trước đây nó yêu cầu cân bằng lại thủ công. HBase xử lý cho bạn nếu bạn muốn. Trình phân vùng được sắp xếp là quan trọng đối với việc xử lý kiểu Hadoop.

• Cassandra và HBase đều phức tạp, Cassandra chỉ ẩn nó tốt hơn. HBase cho thấy nhiều hơn thông qua việc sử dụng HDFS cho lưu trữ của nó, nếu bạn nhìn vào codebase Cassandra cũng giống như lớp. Nếu bạn so sánh các bài báo Dynamo và Bigtable, bạn có thể thấy rằng lý thuyết hoạt động của Cassandra thực sự phức tạp hơn.

• HBase có nhiều kiểm tra đơn vị hơn FWIW.

• Tất cả RPC Cassandra đều tiết kiệm, HBase có một tiết kiệm, REST và Java nguyên gốc. The Thrift và REST chỉ cung cấp một tập hợp con của API khách hàng tổng, nhưng nếu bạn muốn có tốc độ thuần khiết thì trình khách Java nguyên gốc ở đó.

• Có lợi thế cho cả ngang hàng và ngang hàng với người phụ nữ. Thiết lập tổng thể - nô lệ thường làm cho nó dễ dàng hơn để gỡ lỗi và giảm bớt một chút phức tạp.

• HBase không chỉ liên quan đến HDFS truyền thống, bạn có thể thay đổi bộ nhớ cơ bản của mình tùy theo nhu cầu của bạn.MapR trông khá thú vị và tôi đã nghe những điều tốt đẹp mặc dù tôi đã không sử dụng nó bản thân mình.

Answer 2

Là một nhà phát triển Cassandra, tôi là tốt hơn lúc trả lời phía bên kia của câu hỏi:

• Cassandra quy mô tốt hơn. Cassandra được biết đến với tỷ lệ là over 400 nodes in a cluster; khi Facebook triển khai Nhắn tin trên đầu trang của HBase, họ phải di chuyển nó qua số 100-node HBase sub-clusters.
• Cassandra hỗ trợ hàng trăm, thậm chí hàng nghìn ColumnFamilies. "HBase currently does not do well with anything above two or three column families".
• Là hệ thống được phân phối hoàn toàn không có "special" nodes or processes, Cassandra là simpler to set up and operate, dễ khắc phục sự cố và mạnh mẽ hơn.
• Hỗ trợ sao chép đa chủ của Cassandra không chỉ giúp bạn có được sức mạnh hiển nhiên của nhiều trung tâm dữ liệu - dư thừa địa lý, độ trễ cục bộ - nhưng bạn cũng có thể chia khối lượng công việc thời gian thực và phân tích thành các nhóm riêng biệt với realtime, bidirectional replication between them. Nếu bạn không phân chia các khối lượng công việc đó, chúng sẽ tranh luận một cách ngoạn mục.
• Bởi vì mỗi nút Cassandra quản lý lưu trữ cục bộ của riêng mình, Cassandra có một lợi thế hiệu suất đáng kể mà không bị thu hẹp đáng kể. (Ví dụ, đó là tiêu chuẩn thực hành để đặt cam kết Cassandra trên một thiết bị riêng biệt để nó có thể làm tuần tự của nó viết unimpeded bởi ngẫu nhiên i/o từ yêu cầu đọc.)
• Cassandra cho phép bạn chọn mạnh mẽ như thế nào bạn muốn nó yêu cầu nhất quán trên cơ sở từng hoạt động. Đôi khi điều này bị hiểu lầm là "Cassandra không cho bạn sự nhất quán mạnh mẽ", nhưng điều đó là không chính xác.
• Cassandra cung cấp RandomPartitioner cũng như OrderedPartitioner giống Bigtable hơn. RandomPartitioner là ít dễ bị các điểm nóng.
• Cassandra cung cấp họ trực tuyến hay off-đống bộ nhớ đệm với hiệu suất tương đương với memcached, nhưng nếu không có những vấn đề thống nhất bộ nhớ cache hoặc phức tạp của yêu cầu bộ phận chuyển động thêm
• khách hàng Non-Java là công dân không hạng nhì

Theo hiểu biết của tôi, lợi thế chính của HBase hiện nay (HBase 0.90.4 và Cassandra 0.8.4) là Cassandra chưa hỗ trợ nén dữ liệu trong suốt. (Điều này đã được added for Cassandra 1.0, do vào đầu tháng Mười, nhưng ngày nay đó là một lợi thế thực sự cho HBase.) HBase cũng có thể được tối ưu hóa tốt hơn cho các loại quét phạm vi được thực hiện bởi xử lý hàng loạt Hadoop.

Ngoài ra còn có một số thứ không nhất thiết phải tốt hơn, hoặc tệ hơn, chỉ khác nhau. HBase tuân thủ nghiêm ngặt hơn mô hình dữ liệu Bigtable, trong đó mỗi cột được phiên bản hoàn toàn.Cassandra giảm phiên bản, và thêm SuperColumns.

Hy vọng điều đó sẽ hữu ích!

Answer 3

Lý do sử dụng 100 cụm nút hBase không phải vì HBase không mở rộng quy mô lớn hơn. Đó là bởi vì nó là dễ dàng hơn để làm nâng cấp phần mềm hBase/HDFS trên một thời trang lăn mà không đưa xuống toàn bộ dịch vụ của bạn. Một lý do khác là để ngăn chặn một NameNode duy nhất là một SPOF cho toàn bộ dịch vụ. Ngoài ra, HBase đang được sử dụng cho các dịch vụ khác nhau (không chỉ các tin nhắn FB) và thận trọng khi có một phương pháp cắt cookie để thiết lập nhiều cụm HBase dựa trên phương pháp tiếp cận nhóm 100 nút. Số 100 là adhoc, chúng tôi không tập trung vào việc liệu 100 có tối ưu hay không.