[HADOOP] Hbase 스키마 중첩 엔티티

Hbase 스키마 중첩 엔티티

누구나 중첩 된 엔티티와 Hbase 테이블을 만드는 방법에 대한 예제가 있습니까?

예

UserName (string)
SSN  (string)
  + Books (collection)

도서 컬렉션은 다음과 같이 보입니다.

서적

isbn
title
etc...

하나의 예제가 이런 식의 테이블을 만드는 방법을 찾을 수 없습니다. 많은 사람들이 그것에 대해 이야기하고 특정 시나리오에서 이것이 최선의 방법이라고 말하는 것을 볼 수 있지만 어디서나 할 수있는 방법에 대한 예제는 찾을 수 없습니다.

감사...

해결법

1. ==============================

   1.중첩 된 엔티티는 HBase의 공식 기능이 아닙니다. 이는 사람들이 한 가지 사용 패턴에 대해 말하는 방식 일뿐입니다. 이 패턴에서, HBase의 "columns"는 실제로 행의 하나당 하나의 열을 추가하여 행 내부의 카디널리티 차원을 모델링 할 수 있도록하는 큰지도 (키 / 값 쌍)입니다. 상자의 엔티티

   중첩 된 엔티티는 HBase의 공식 기능이 아닙니다. 이는 사람들이 한 가지 사용 패턴에 대해 말하는 방식 일뿐입니다. 이 패턴에서, HBase의 "columns"는 실제로 행의 하나당 하나의 열을 추가하여 행 내부의 카디널리티 차원을 모델링 할 수 있도록하는 큰지도 (키 / 값 쌍)입니다. 상자의 엔티티

   스키마 적으로, 테이블 자체에 많은 것을 할 필요가 없다. HBase에서 테이블을 만들 때 (hbase 쉘에서와 같이) 이름 및 열 패밀리 (및 관련 속성) 만 지정하면됩니다.

   hbase:001:0> create 'UserWithBooks', 'cf1'
   

   그런 다음, 당신이 그것에 넣은 것은 현명한 것입니다. 다음과 같은 값을 삽입 할 수 있습니다.

   hbase:002:0> put 'UsersWithBooks', 'userid1234', 'cf1:username', 'my username'
   hbase:003:0> put 'UsersWithBooks', 'userid1234', 'cf1:ssn', 'my ssn'
   hbase:004:0> put 'UsersWithBooks', 'userid1234', 'cf1:book_id_12345', '<isbn>12345</isbn><title>mary had a little lamb</title>'
   hbase:005:0> put 'UsersWithBooks', 'userid1234', 'cf1:book_id_67890', '<isbn>67890</isbn><title>the importance of being earnest</title>'
   

   컬럼 이름은 완전히 당신에게 달려 있으며, 당신이 가질 수있는 수에 제한이 없습니다 (이유에 대해서는 HBase Reference Guide를보십시오). 물론, 이것을하는 것, 당신은 자신의 다리 작업을 다시해야한다 : 값을 넣고내는 것 (그리고 나는이 쉘 명령어로하고있는 것보다 더 정교한 방법으로 자바 클라이언트를 사용한다. 단지 설명을 목적으로). 그리고 열 (column) 매김 필터를 사용하여 키에 의해 테이블의 일부 열을 효율적으로 스캔 할 수는 있지만 셀의 내용을 가져 와서 다른 곳에서 구문 분석하는 것 이외에는 그다지 많은 작업을 수행 할 수 없습니다.

   왜 이럴거야? 아마 하나의 부모 행에 대해 모든 중첩 된 행 주위에 원 자성을 원한다면. 그다지 일반적이지는 않습니다. 아마 최선의 방법은 그것들을 별도의 테이블로 모델링하여 시작하는 것입니다. 단점을 실제로 이해한다면이 방법으로 이동하십시오.

2. ==============================

   2.이것에는 몇 가지 제한이 있습니다. 첫째,이 기법은 한 단계 깊숙이 : 중첩 된 엔티티 자체가 중첩 된 엔티티를 가질 수 없습니다. 너는 여전히 할 수있어. 단일 상위에 여러 개의 서로 다른 중첩 된 하위 엔터티가 있고 열 한정자가 해당 특성을 식별합니다. 둘째, 중첩 열로 저장된 개별 값에 액세스하는 것이 효율적이지 않습니다. 배운대로 다른 테이블의 행에 액세스하는 것과 비교할 때 행 내부의 한정자 이 장 앞부분. 여전히 이러한 종류의 스키마 설계가 적절한 경우가 있습니다. 만약 하위 엔티티에서 얻을 수있는 유일한 방법은 상위 엔티티를 통해 이루어 지므로 부모의 모든 하위 엔트리를 트랜잭션 방식으로 보호하려는 경우 이것이 올바른 방법 일 수 있습니다.

   이것에는 몇 가지 제한이 있습니다. 첫째,이 기법은 한 단계 깊숙이 : 중첩 된 엔티티 자체가 중첩 된 엔티티를 가질 수 없습니다. 너는 여전히 할 수있어. 단일 상위에 여러 개의 서로 다른 중첩 된 하위 엔터티가 있고 열 한정자가 해당 특성을 식별합니다. 둘째, 중첩 열로 저장된 개별 값에 액세스하는 것이 효율적이지 않습니다. 배운대로 다른 테이블의 행에 액세스하는 것과 비교할 때 행 내부의 한정자 이 장 앞부분. 여전히 이러한 종류의 스키마 설계가 적절한 경우가 있습니다. 만약 하위 엔티티에서 얻을 수있는 유일한 방법은 상위 엔티티를 통해 이루어 지므로 부모의 모든 하위 엔트리를 트랜잭션 방식으로 보호하려는 경우 이것이 올바른 방법 일 수 있습니다.

from https://stackoverflow.com/questions/14511708/hbase-schema-nested-entity by cc-by-sa and MIT license