Cloudera CDH/CDP 및 Hadoop EcoSystem, Semantic IoT등의 개발/운영 기술을 정리합니다. gooper@gooper.com로 문의 주세요.
대용량 서비스 분야에서 RDBMS의 대안이라고 하는 NoSQL 계열을 들여다 보고 있는 중이다. 아키텍쳐나 설정 방법 등은 대충 알겠는데, 막상 구체적인 응용으로 넘어가보려고 하면, 덜컥 막히는 부분이 바로, 스키마 설계다. 기존의 RDBMS와는 관점과 방법이 완전 다르다. 너무 낯설고 막막해진다.
다음은, 테이블 설계 방법에 대한 설명 문서들이다.
http://www.slideshare.net/hmisty/20090713-hbase-schema-design-case-studies
- Hbase Schema Design Case Studies
- 간략한 비교 발표 자료
- RDBMS에서의 사례와 HBase에서의 사례를 비교
- 설명이 너무 없어서, 다소 막막함
http://data-tactics.com/techtips/cloud_data_structure_diagramming.pdf
- Cloud Data Structure Diagramming Techniques and Design Patterns
- DDI (Denormalization, Duplication, Intelligent keys) methodology
- 꽤 상세한 사례 설명. UML 사용해서 설명.
- 너무 일반적인 규칙을 뽑아내려고 시도(?)하는 바람에 다소 설명이 복잡해짐
- Employee와 Department 테이블을 사례로 설명.
- 다음은, 전통적인(?) RDB 모델
- 다음은, RDB 스타일로 구성한 BigTable
- 다음은, Denormalization 원리를 적용해서, 테이블을 하나로 만들고, 보조 인덱스 테이블을 하나 만듬.
- 다음은, Denormalization과 Duplication을 적용한 경우
- 다음은, Employee hasMany Department 인 경우,
- Many-to-many relationship between Department and Employee 는 아래와 같이 구현도 가능.
http://isabel-drost.de/hadoop/slides/ecircle.pdf
- 간만에 건진, 좋은 문서
- 테이블 설계에 있어, 일종의 패턴을 보여준다.
- Credid-Card Processing 사례를 중심으로 설명
- 다음은, RDB 모델.
- 다음은, HBase 모델
- 위의 테이블에 더해서, email로 해당 카드번호를 찾을 수 있도록 Email to Card Mapping 테이블 준비
- 실제 데이터를 쿼리하는 사례는, 너무 많아서, 여기서는 요약을 생략함. 원문 참조 요망.
http://devblog.streamy.com/2009/04/23/hbase-row-key-design-for-paging-limit-offset-queries/
- HBase 101: Row key design for paging (LIMIT, OFFSET) queries
- SELECT id, name, stamp FROM actions WHERE userid = 1 ORDER BY stamp DESC LIMIT 10 OFFSET 20;
- 위와 비슷한 동작을 하도록 만드는 방법을 설명.
- useraction 테이블을 만드는 데, row key는 복합키. <userid><reverse_order_stamp><actionid> 4바이트 + 8바이트 + 4바이트. 컬럼은 그냥 name 필드 하나만.
- 자세한 자바 코드는, 원문 참조. 이해하기 어렵지 않음.
http://www.yes24.com/24/goods/3858447
- Hadoop 완벽 가이드 : 클라우드 컴퓨팅 구축을 위한 실전 안내서
- 12장 HBase 예제 p. 461 스키마
- stations 테이블: stationid 가 rowkey, info:name, info:location, info:description 칼럼
- observations 테이블: stationid + reversed_timestamp 가 rowkey, data:airtemp 칼럼
- 관측치 테이블인 observations의 로우키를 복합키로 만든 이유는, 이 테이블에서 해당 stationid의 가장 최신 관측값을 10개 가져오려 하기 때문임. reserved_tmestamp = LONG.MAX_VALUE – observationTime 으로 계산.
- rowkey의 접두사가 stationid 이므로, 같은 stationid를 가지는 row들이 차례대로 정렬됨. 따라서, Scanner로 시작점을 설정하고, s.next()로 읽어내면서 maxCount(=10)까지만 읽으면 됨.
대략, 느낌을 몇 가지 정리해보면, 아래와 같다.
RDB와는 다르게, 컬럼 필드에 대해서는 인덱스 생성이 자동으로 안된다. 오로지 RowKey에 대해서만 자동으로 인덱스 된다. 따라서, 컬럼 필드를 where 조건에서 지정해서 뽑아내는 식은 안된다. 무조건 RowKey로만 찾을 수 있다. 따라서, RowKey를 아주 영리하게 잘 설계해야 한다.
JOIN 같은 건 아예 지원 안된다. 테이블을 겹치지 않게 쪼개놓고 그걸 나중에 JOIN하겠다는 생각 자체를 하지 말아야 한다. 그 대신, 그냥, 한 테이블에 관련 정보를 컬럼 패밀리로 나눠서 때려 넣고, 필요한 걸 뽑아내는 방식이 더 낫다.