Xử lý dữ liệu quy mô lớn Hbase vs Cassandra [đóng cửa]


84

Tôi sắp 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à nơi lưu trữ khóa / giá trị giống nhau và cả hai đều đang / có thể chạy (gần đây là Cassandra) lớp Hadoop thì điều khiến Hadoop trở thành ứng cử viên tốt hơn khi yêu cầu xử lý / phân tích trên dữ liệu lớn.

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

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

Trong khi tôi bị thuyết phục nhiều hơn về Cassandra vì tính đơn giản của nó để thêm các nút và sao chép liền mạch và không có điểm lỗi. Và nó cũng giữ tính năng chỉ mục phụ nên một điểm cộng tốt của nó.

Câu trả lời:


91

Việc cố gắng xác định cái nào tốt nhất cho bạn thực sự phụ thuộc vào việc bạn sẽ sử dụng nó cho mục đích gì, mỗi cái đều có lợi thế của mình và nếu không có thêm chi tiết thì nó sẽ trở thành một cuộc chiến tôn giáo hơn. Bài đăng mà bạn tham khảo 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 với những phát triển gần đây của Cassandra.

Sau khi nói điều đó, tôi sẽ diễn giải người cam kết HBase là Andrew Purtell và thêm một số kinh nghiệm của riêng tôi:

  • HBase đang ở trong các môi trường sản xuất lớn hơn (1000 nút) mặc dù điều đó vẫn còn trong vòng tròn cài đặt ~ 400 nút của Cassandra vì vậy nó thực sự là một sự khác biệt nhỏ.

  • 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ếp xúc nhiều hơn với người dùng nên nó có vẻ 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 mạnh mẽ là những gì ứng dụng của bạn cần thì HBase có thể sẽ phù hợp hơn. Nó được thiết kế từ cơ sở trở lên để nhất quán. 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 chỉ có chúng) cũng như các hoạt động Kiểm tra và Đặt.

  • Hiệu suất viết là rất tốt, theo những gì tôi hiểu, đó là một trong những lý do Facebook sử dụng HBase cho trình nhắn tin của họ.

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

  • Cassandra và HBase đều phức tạp, Cassandra chỉ che giấu nó tốt hơn. HBase bộc lộ nó nhiều hơn thông qua việc sử dụng HDFS để lưu trữ, nếu bạn nhìn vào cơ sở mã Cassandra cũng giống như lớp. Nếu bạn so sánh tài liệu 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 bài kiểm tra đơn vị hơn FWIW.

  • Tất cả Cassandra RPC là Thrift, HBase có Thrift, REST và Java bản địa. Thrift và REST chỉ cung cấp một tập hợp con của tổng số API ứng dụng khách nhưng nếu bạn muốn tốc độ thuần túy thì ứng dụng khách Java gốc sẽ ở đó.

  • Có những lợi thế cho cả ngang hàng và chủ đối với nô lệ. Thiết lập chủ - tớ thường giúp gỡ lỗi dễ dàng hơn và giảm khá nhiều độ phức tạp.

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


117

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

  • Cassandra quy mô tốt hơn. Cassandra được biết là có quy mô tới hơn 400 nút trong một cụm ; khi Facebook triển khai Messaging trên HBase, họ phải chia nhỏ nó trên các cụm con HBase 100 nút .
  • Cassandra hỗ trợ hàng trăm, thậm chí hàng nghìn ColumnFamilies. " HBase hiện không hoạt động tốt với bất cứ thứ gì trên hai hoặc ba họ cột ."
  • Là một hệ thống phân tán hoàn toàn không có các nút hoặc quy trình "đặc biệt" , Cassandra dễ thiết lập và vận hành hơn, dễ khắc phục sự cố hơn và mạnh mẽ hơn.
  • Sự hỗ trợ của Cassandra đối với sao chép đa tổng thể có nghĩa là bạn không chỉ có được sức mạnh rõ ràng của nhiều trung tâm dữ liệu - dư thừa địa lý, độ trễ cục bộ - mà bạn còn có thể chia khối lượng công việc phân tích và thời gian thực thành các nhóm riêng biệt, với thời gian thực, sao chép hai chiều giữa chúng . Nếu bạn không chia nhỏ các khối lượng công việc đó thì chúng sẽ cạnh tranh ngoạn mục.
  • Bởi vì mỗi nút Cassandra quản lý bộ nhớ 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 có khả năng bị thu hẹp đáng kể. (Ví dụ: thông lệ tiêu chuẩn là đặt cam kết Cassandra trên một thiết bị riêng biệt để nó có thể thực hiện việc ghi tuần tự mà không bị cản trở bởi i / o ngẫu nhiên từ các yêu cầu đọc.)
  • Cassandra cho phép bạn chọn mức độ mạnh mẽ mà bạn muốn nó yêu cầu tính nhất quán trên cơ sở mỗi hoạt động. Đôi khi điều này bị hiểu nhầm là "Cassandra không mang lại cho bạn sự kiên định 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 ít bị điểm nóng hơn nhiều.
  • Cassandra cung cấp bộ nhớ đệm on-hoặc off-heap với hiệu suất tương đương với memcached, nhưng không có vấn đề về tính nhất quán của bộ nhớ cache hoặc sự phức tạp của việc yêu cầu thêm các bộ phận chuyển động
  • Máy khách không phải Java không phải là công dân hạng hai

Theo hiểu biết của tôi, lợi thế chính mà HBase có ngay bây giờ (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 thêm vào cho Cassandra 1.0 , sẽ ra mắt vào đầu tháng 10, 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.

Cũng có một số thứ không nhất thiết phải tốt hơn, hoặc tệ hơn, chỉ là khác biệt. 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 ngầm. Cassandra bỏ lập phiên bản và thay vào đó thêm SuperColumns.

Hy vọng rằng sẽ giúp!


13
Tôi khá chắc chắn rằng Facebook phân đoạn trên 100 cụm HBAse nút vì những lý do khác liên quan đến ngăn xếp phần mềm mô-đun của họ. Tại một cuộc nói chuyện gần đây, Todd Lipcon từ Cloudera đã đề cập đến các cụm HBase 1PT 1000 nút và tôi đã thấy đề cập đến hơn 700 cụm HBase nút.
cftarnas

1
Điểm tốt. Nó cũng có thể là một cái gì đó cụ thể về khối lượng công việc.
jbellis

1
Rất nhiều ưu điểm của Cassandra ở trên. Nhưng tại sao Facebook lại chọn HBase thay vì Cassandra !?
Ivan Voroshilin

5
Một sự kết hợp của (a) những người trong nhóm Nhắn tin đã quen thuộc với Hadoop và HBase, (b) kém hiểu biết về mô hình nhất quán của Cassandra và (c) không liên hệ với cộng đồng Apache Cassandra để được trợ giúp về (b). Gần đây hơn, các bộ phận trên facebook như Instagram và Parse đã chọn Cassandra: planetcassandra.org/blog/post/… planetcassandra.org/blog/post/…
jbellis

23

Lý do sử dụng cụm 100 nút hBase không phải vì HBase không mở rộng đến kích thước lớn hơn. Đó là bởi vì việc nâng cấp phần mềm hBase / HDFS theo cách luân phiên sẽ dễ dàng hơn mà không làm giảm toàn bộ dịch vụ của bạn. Một lý do khác là ngăn một Mã tên duy nhất trở thành 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ỉ tin nhắn FB) và cần thận trọng khi có phương pháp cắt cookie để thiết lập nhiều cụm HBase dựa trên phương pháp nhóm 100 nút. Con số 100 là đúng, chúng tôi chưa tập trung vào việc liệu số 100 có phải là tối ưu hay không.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.