HDFS 위에서 구동됨

1. non-relational, scalable database
2. query는 안되고 API만 존재함 → key : value

Google’s BigTable을 기반으로 만들어짐

1. 검색엔진이 저장하고있는 페이지 정보들을 저장하는 방식을 공개함

CRUD 가능

기본구조

• region → key ranges → sharding이나 partition과 비슷한 개념이라고 보면 됨
  • 데이터 양이 늘어나면 런타임에 자동으로 region이 늘어남
  • 일반적인 sharding은 commit, merge 등등 작업을 해줘야하는데 HBase는 그럴 필요가 없다
• HDFS위에서 돌아감 → 분산되어있음
  • region server에서 가지고 있는 row들을 더 큰 규모의 파일로 모아서 HDFS에 저장할 수도 있음
  • 전에 이야기했던 block들로 저장 가능하다는 뜻인듯
• HBase와 소통하는 application은 HMaster와 소통하지 않고 region server하고 소통함
  • HMaster는 데이터베이스의 schema를 저장함
  • 뭐가 어디있고 이런 정보들
• Zookeeper → Highly available system
  • 어떤 HMaster가 잘 돌고 있는지 파악
  • 예전에 HDFS에서 name node죽으면 어떻게 할지 파악하는 역할을 했었는데 HBase에서도 함

data model

1. ROW에 빠르게 접근할 수 있음

2. Row는 key를 사용해서 접근함

   1. key - value pair

3. 각각의 row는 Column family가 있음

   1. 각각의 column family가 column들의 정보를 가지고 있음
   2. 영화 rating을 예로 들면, key가 사람이라고 할 때 column family가 영화제목들이 됨
   3. 모든 사람이 모든 Column에 데이터를 가지고 있을 필요는 없음
      • column이 비어있을 때 storage를 차지하지도 않음
   4. column family와 column의 1 - 1 mapping도 가능하긴함

4. 갑자기 cell이라는 이야기를 하는데

   1. intersection of row and a column
   2. timestamp에 따라 다양한 버전 관리가 다양하다고 함

5. 예제 → anchor 가 뭔지 이해가 잘 안됨

   

   • key가 lexicographilcally 저장됨 → 알파벳 순이라고 보면 된다함
     • www가 뒤로감 → XXX.cnn.com이런것들 다 엮기위해서
   • contents column family → contents만 가지고있음
     • version 정보가 있음. 마지막 3번 크롤링만 저장함
   • anchor column family → cnn.com으로 연결되는 사이트들
     • cnn.com에 접근하는 사이트들

접근법

1. HBase shell
2. Java API
   1. wrapper for Python, Scala
3. Spark,Hive, Pig
4. REST → HTTP requests
5. Thrift → facebook
   1. binary format.
   2. 정보 저장 더 효율적이고 전송도 빠름
   3. 근데 클라이언트하고 서버하고 잘 커플링되어야함 (버전정보 등등)
6. Avro → hadoop