Hbase 문서에서는 실제 열을 열 패밀리로 수행하므로 유사한 열을 열 패밀리로 그룹화해야한다는 점을 분명히합니다.Hadoop Hbase : 테이블간에 열 패밀리를 확산하지 않았습니까?
그러나 열 그룹마다 별도의 테이블을 사용하는 것과는 달리 두 열을 동일한 테이블에 넣는 것은 무엇을 의미합니까? 이 방법으로 테이블을 "파티셔닝"하는 것이 더 합당한 경우와 "넓은"테이블이 더 잘 작동하는 경우가 있습니까?
별도의 테이블은 별도의 "행 영역"을 만들어야하며 일부 열 패밀리 (전체적으로)가 매우 희소 할 때 유용 할 수 있습니다. 반대로, 열매를 함께 모으는 것이 언제 유익합니까?
열 가족에 대한 아이디어가 있습니다. 기본적으로 빠른 액세스를 위해이 항목들을 함께 저장하고 복제하는 것은 HBase에 대한 힌트 일뿐입니다.
동일한 테이블에 두 개의 열 패밀리를 놓고 항상 서로 다른 키를 사용하면 서로 다른 두 테이블에있는 것과 동일한 결과를 얻습니다. 동일한 테이블을 통해 동일한 키를 통해 액세스되는 두 개의 열 패밀리 만 있으면됩니다.
예 : 주어진 웹 사이트의 총 페이지 뷰 수, 동일한 사이트의 고유보기 수, 사용자가 사이트를 보는 데 사용하는 브라우저 및 인터넷 연결 수에 대한 열이있는 경우 첫 번째 두 개를 세로 열 패밀리로, 마지막 두 개를 다른 세로 막 대형으로 사용하기로 결정하십시오. 여기 네 가지 모두 동일한 열쇠, 즉 문제의 웹 사이트에 의해 접근되므로 같은 테이블에 두어서 얻고 있습니다.
다른 테이블에 있다면 두 테이블에서 조인과 같은 작업을 수행해야 할 것입니다. 그렇긴하지만 실제로 숫자를 알지 못하기 때문에 조인과 같은 작업이 얼마나 느린지를 말할 수는 없습니다. (HBase가 비 관계형이기 때문에 조인을 기억하지 않기 때문에) 그리고 전환점이 어디에서 나뉘어 지는지 그 (것)들을 분리되는 테이블로 동일한 테이블 (또는 그 반대)에서있는 그들보다 중요하다.
물론이 모든 것은 저장하려는 데이터에 따라 달라 지므로 테이블간에 조인 할 필요가 없다면 별도의 테이블에 보관할 수 있습니다. 처음에는 서로 관련이 있습니다.
열 패밀리는 행 지향과 열 기반 액세스 간의 절충안입니다. Chris의 웹 페이지 예제를 확장하기 위해 행 액세스는 단일 웹 사이트에 대한 모든 데이터 (열)를 가져옵니다. 열 기반 연산의 예는 모든 사이트에서 페이지 뷰 수를 합하는 것입니다.
후자의 작업에는 브라우저 및 연결 세부 정보가 필요하지 않습니다. 브라우저 및 연결 세부 정보는보기 횟수에 대한 숫자 값보다 훨씬 커서 쿼리 성능에 큰 영향을줍니다. 따라서 HBase는 열 작업을 지원하는 최적화로 열 패밀리를 제공합니다.
열이 동일한 테이블에 있어야하는지에 관해서는 ... 일반적인 엔티티 모델링 가이드 라인을 따르고 같은 엔티티의 특성 일 경우 모든 열을 같은 테이블에 넣을 것입니다. 열 패밀리는 스키마가 아닌 성능에 관한 것입니다.
"열 패밀리는 스키마가 아닌 성능에 관한 것입니다." 방금 전에 말하기 전까지는 분명하지 않았습니다. 고맙습니다. –
당신은 "가입은 비쌉니다"라고 말합니다. 이는 동일한 테이블 내의 열 그룹 간의 "조인"이 테이블의 열 그룹 조인보다 비용이 적게 든다는 것을 의미하는 것으로 보입니다. 그럴까요? HBase 문서는 그렇게 명확하지 않다고 생각합니다. – Thilo
이름이 같은 두 개의 열이있는 'get'연산이고 쿼리 언어의 기본 요소이기 때문에 동일한 테이블의 열 사이에 '조인'을하는 것이 훨씬 저렴하다고 생각합니다. 그러나 '가입'은 원시적 인 것이 아니므로 직접 구현해야합니다 (더 많은 작업이 필요함). –