대규모 데이터 처리 Hbase 대 Cassandra [닫기]

대규모 데이터 저장 솔루션에 대한 연구를 마치고 Cassandra에 거의 도착했습니다. 그러나 일반적으로 Hbase가 대규모 데이터 처리 및 분석에 더 나은 솔루션이라고 말합니다.

둘 다 동일한 키 / 값 저장소이고 둘 다 실행 / 실행될 수 있지만 (Cassandra 최근) Hadoop 계층이 대용량 데이터에 대한 처리 / 분석이 필요할 때 Hadoop을 더 나은 후보로 만드는 이유입니다.

또한 http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/ 에서 둘 다에 대한 좋은 세부 정보를 찾았습니다.

그러나 나는 여전히 Hbase의 구체적인 장점을 찾고 있습니다.

노드를 추가하고 원활한 복제를 수행하고 장애 지점 기능이 없기 때문에 Cassandra에 대해 더 확신합니다. 또한 보조 인덱스 기능을 유지하므로 좋은 장점이 있습니다.

어떤 것이 당신에게 가장 적합한 지 결정하려고 노력하는 것은 당신이 그것을 무엇에 사용할 것인지에 달려 있으며, 그들 각각은 장점이 있으며 더 이상 세부 사항이 없으면 종교 전쟁에 가깝습니다. 참조하신 게시물도 1 년이 넘었으며 그 이후로 많은 변화를 겪었습니다. 또한 최근의 Cassandra 개발에 익숙하지 않다는 점을 기억하십시오.

그렇게 말하면서 HBase 커미터 Andrew Purtell을 의역하여 내 경험을 추가하겠습니다.

• HBase는 더 큰 프로덕션 환경 (1000 노드)에 있지만 Cassandra의 ~ 400 노드 설치의 구장에 있기 때문에 실제로는 약간의 차이가 있습니다.

• HBase와 Cassandra는 모두 클러스터 / 데이터 센터 간의 복제를 지원합니다. 나는 HBase가 사용자에게 더 많이 노출되므로 더 복잡해 보이지만 더 많은 유연성을 얻을 수 있다고 생각합니다.

• 강력한 일관성이 애플리케이션에 필요한 것이라면 HBase가 더 적합 할 것입니다. 처음부터 일관성있게 설계되었습니다. 예를 들어 원자 카운터 (Cassandra가 방금 가져온 것 같음)와 Check 및 Put 작업을 더 간단하게 구현할 수 있습니다.

• Facebook이 메신저를 위해 HBase를 사용하는 이유 중 하나라는 점을 제가 이해 한 바에 따르면 쓰기 성능은 훌륭합니다.

• Cassandra의 주문한 파티 셔 너의 현재 상태는 확실하지 않지만 과거에는 수동 재조정이 필요했습니다. HBase는 원하는 경우이를 처리합니다. 주문 된 파티 셔 너는 Hadoop 스타일 처리에 중요합니다.

• Cassandra와 HBase는 둘 다 복잡하고 Cassandra는 더 잘 숨 깁니다. 코드베이스 Cassandra를 살펴보면 HBase는 HDFS를 사용하여 더 많이 노출합니다. Dynamo와 Bigtable 논문을 비교하면 Cassandra의 작동 이론이 실제로 더 복잡하다는 것을 알 수 있습니다.

• HBase에는 더 많은 단위 테스트 FWIW가 있습니다.

• 모든 Cassandra RPC는 Thrift이고 HBase에는 Thrift, REST 및 네이티브 Java가 있습니다. Thrift 및 REST는 전체 클라이언트 API의 하위 집합 만 제공하지만 순수한 속도를 원한다면 네이티브 Java 클라이언트가 있습니다.

• 피어 투 피어 및 마스터 투 슬레이브 모두에 ​​이점이 있습니다. 마스터-슬레이브 설정은 일반적으로 디버그를 더 쉽게 만들고 복잡성을 상당히 줄여줍니다.

• HBase는 기존 HDFS에만 연결되어 있지 않으며 필요에 따라 기본 스토리지를 변경할 수 있습니다. MapR 은 꽤 흥미로워 보이며 직접 사용하지는 않았지만 좋은 소식을 들었습니다.

Cassandra 개발자로서 저는 질문의 다른면에 더 잘 대답합니다.

• Cassandra는 더 잘 확장됩니다. Cassandra는 클러스터에서 400 개 이상의 노드 로 확장되는 것으로 알려져 있습니다 . Facebook이 HBase 위에 Messaging을 배포 할 때 100 노드 HBase 하위 클러스터에 걸쳐 샤딩해야했습니다 .
• Cassandra는 수백, 심지어 수천 개의 ColumnFamilies를 지원합니다. " HBase는 현재 2 개 또는 3 개의 컬럼 제품군 이상에서는 잘 작동하지 않습니다 ."
• "특별한"노드 나 프로세스 가없는 완전 분산 형 시스템 인 Cassandra는 설치 및 운영 이 더 간단하고 문제 해결이 더 쉽고 견고합니다.
• 다중 마스터 복제에 대한 Cassandra의 지원은 지리적 중복성, 로컬 대기 시간과 같은 다중 데이터 센터의 분명한 힘을 얻을 수있을뿐만 아니라 실시간 및 분석 워크로드를 개별 그룹으로 분할 하여 이들간에 실시간 양방향 복제를 수행 할 수 있음을 의미합니다 . 이러한 워크로드를 분리하지 않으면 놀라 울 정도로 경쟁 할 것입니다.
• 각 Cassandra 노드는 자체 로컬 저장소를 관리하기 때문에 Cassandra는 크게 축소 될 가능성이없는 상당한 성능 이점이 있습니다. (예를 들어, Cassandra 커밋 로그를 별도의 장치에 배치하여 읽기 요청의 임의 I / O에 의해 방해받지 않고 순차 쓰기를 수행하는 것이 표준 관행입니다.)
• Cassandra를 사용하면 작업별로 일관성을 유지하는 데 필요한 강도를 선택할 수 있습니다. 때때로 이것은 "카산드라가 당신에게 강력한 일관성을주지 않는다"고 오해하지만, 그것은 잘못된 것입니다.
• Cassandra는 RandomPartitioner와 Bigtable과 유사한 OrderedPartitioner를 제공합니다. RandomPartitioner는 핫스팟에 덜 취약합니다.
• Cassandra는 memcached에 필적하는 성능으로 온 또는 오프 힙 캐싱을 제공하지만 캐시 일관성 문제 또는 추가 이동 부품이 필요한 복잡성이 없습니다.
• 비 Java 클라이언트는 2 등급 시민이 아닙니다.

내가 아는 한, HBase가 현재 가지고있는 주요 이점 (HBase 0.90.4 및 Cassandra 0.8.4)은 Cassandra가 아직 투명한 데이터 압축을 지원하지 않는다는 것입니다. (이것은 10 월 초에 예정된 Cassandra 1.0 에 추가 되었지만 오늘은 HBase의 실질적인 이점입니다.) HBase는 Hadoop 일괄 처리로 수행되는 범위 스캔의 종류에 대해 더 잘 최적화 될 수 있습니다.

또한 반드시 더 좋거나 더 나쁘지 않은 것들이 있습니다. HBase는 각 열이 암시 적으로 버전이 지정되는 Bigtable 데이터 모델을 더 엄격하게 준수합니다. Cassandra는 버전 관리를 중단하고 대신 SuperColumns를 추가합니다.

도움이 되었기를 바랍니다.

100 개의 노드 hBase 클러스터를 사용하는 이유는 HBase가 더 큰 크기로 확장되지 않기 때문이 아닙니다. 전체 서비스를 중단하지 않고 롤링 방식으로 hBase / HDFS 소프트웨어 업그레이드를 수행하는 것이 더 쉽기 때문입니다. 또 다른 이유는 단일 NameNode가 전체 서비스에 대한 SPOF가되지 않도록하는 것입니다. 또한 HBase는 다양한 서비스 (FB 메시지뿐만 아니라)에 사용되고 있으며 100 노드 포드 접근 방식을 기반으로 수많은 HBase 클러스터를 설정하는 쿠키 커터 접근 방식을 갖는 것이 현명합니다. 숫자 100은 임시적이며 100이 최적인지 아닌지에 대해서는 초점을 두지 않았습니다.