hbase 테이블을 더 작은 엔티티로 분할 할 이유가 있을까요, 아니면 영원히 커질 수 있습니까? (사용 가능한 디스크 공간을 가정 할 때)?실제로 hbase 테이블의 크기는 얼마나 커질 수 있습니까?
배경 :
에 본질적으로 타임 스탬프 값, 플래그로 구성되어 50 만/s의, 말할 수까지 우리는 실시간 데이터 (측정)을 가지고있다. 값을 다른 테이블에 분산 시키면 각 항목을 개별적으로 삽입하는 것을 의미합니다. 이는 성능 저하 요인입니다. 대량으로 삽입하면 훨씬 빠릅니다. 문제는 극단적 인 크기의 hbase 테이블을 가질 때의 단점이 있습니까?
내가 수동으로 HBase를 테이블을 분할에있는 점을 볼 수 없습니다, HBase를은 (HBase table regions라고하는) 매우 잘이 독자적으로 수행하고
HBase와는 매우 큰 데이터를 처리하기위한 것으로, 그래서 나는에 좋아 (물론 구성이 자동 메이저 압축 등과 같은 성능에 영향을 줄 수 있습니다.)
영역 서버 핫 스폿을 피하는 강력한 이유가있을 수 있습니다. 로드를 여러 RegionServers에 분산시켜야합니다. HBase는 그 특성상 행을 한 곳에서 순차적으로 저장합니다. 유사한 키가있는 행은 동일한 서버 (예 : timeseries 데이터)로 이동합니다. 이는 더 나은 범위 쿼리를 용이하게하기위한 것입니다. 그러나 데이터가 너무 커지면 (그리고 디스크에 여전히 공간이있는 경우) 병목 현상이 발생하기 시작합니다.
위의 경우 데이터는 동일한 RegionServer로 계속 이동하여 핫스팟을 만듭니다. 그래서 우리는 테이블을 수동으로 분할하여 데이터를 클러스터 전체에 균일하게 배포합니다.