P08-C06 HBase

1 HBase의 탄생 배경

1.1 RDBMS의 문제점

1.1.1 읽기 부하

• 데이터 증가 → 탐색 속도 저하

  • RDBMS는 데이터가 많아질수록 디스크 I/O가 증가한다.
  • 디스크에서 원하는 레코드를 찾기 위해 랜덤 액세스를 수행하고, 해당 블록을 페이지 단위로 메모리 캐시에 로드한 후 탐색한다.
  • 원하는 데이터가 없을 경우, 다시 디스크를 탐색해야 하므로 데이터량이 커질수록 탐색 경로가 길어지고 성능이 떨어진다.

• 캐시 도입

  • 읽기 성능 개선을 위해 캐시(메모리 상의 버퍼 풀)를 사용한다.
  • 하지만 캐시된 데이터는 최신 데이터와 차이가 있을 수 있으며, 이로 인한 view 격차(staleness)를 최소화하는 것이 중요하다.

1.1.2 쓰기 부하

더이상 저장할 수 있는 용량이 안되면 아니면 데이터 양에 비해 리소스가 적어 검색수가 너무 오래 걸린다고 하면 기본적으로 메모리가 많이 필요하니까 Scale-up을 해야함.

• Scale-up 한계
  • 데이터가 증가하면 단일 서버의 성능을 높여야 하는데, 이는 비용 증가로 이어진다.

보통 마스터슬레이브에서 데이터 복제본이 유지되어서 유실되지 않도록 할 텐데 슬레이브도 비스산 성능으로 맞춰 줘야 안 쓰는 복제본도 고사양의 컴퓨터를 놔야 된다는 것도 쓰기에서 단점이다.

• 복제 부담
  • 읽기 부하 분산을 위해 슬레이브 DB를 두더라도, 마스터와 동일한 수준의 성능/용량을 요구한다.
  • 또한, 쓰기 시 모든 슬레이브로 데이터 동기화를 보장해야 하므로 추가적인 부하가 발생한다.

1.1.3 데이터 규모 증가 시 문제

• 데이터가 많아지면 전반적인 쿼리 성능이 저하된다.

• 기능 제한을 통해 성능을 유지해야 한다:

  • 보조 색인 제거: 기본키(PK) 이외의 색인은 쓰기 성능을 저하시켜서 대규모 데이터 환경에서는 유지하기 어렵다. (메모리 많이 쓰니까)
  • 기능 단순화: RDBMS가 제공하는 다양한 기능(SQL 조인, 트랜잭션 등)을 모두 쓰기 어려워진다.

• 샤딩(Sharding)

  • 데이터를 여러 DB 인스턴스로 나누어 저장하는 방식이다.
  • 하지만 샤딩 키 설계, 샤드 간 조인, 데이터 이동/균형화 관리가 매우 복잡하다.

1.1.4 Sharding

Sharding은 수평적 파티션으로 레코드를 논리적으로 분할하는 방식이다.
핵심은 파티션 간 고정된 경계와 라우팅 규칙을 사전에 정의하여, 특정 키가 어느 파티션(샤드)로 갈지 일관되게 결정하는 데 있다.

운영 중 resharding이 필요해지면 본질적 어려움이 따른다

• 저장 구조를 다시 작성해야 하고
• 데이터 재분배로 일시적 부하가 급증하여 입출력 성능에 큰 타격을 줄 수 있다.

이를 완화하기 위해 virtual shard를 사용한다.

• 매우 큰 키 공간을 기준으로 충분히 많은 가상 샤드를 먼저 만들고, 실제 서버 수와 무관하게 가상 샤드를 균등 분배한다.
• 서버를 증설/축소할 때는 가상 샤드만 재할당하면 된다
• 일반적으로 consistent hashing을 이용해 재배치 범위(데이터 이동량)를 최소화한다(단, 데이터 이동은 불가피하다).

이런 설계를 초기에 고려하지 않고 나중에 도입하면, 라우팅 변경·데이터 이동·다운타임 관리 등에서 큰 혼란이 발생한다.

1.2 비관계형 데이터베이스 시스템의 고려사항

1.2.1 Column oriented storage

1. 가정: 특정 쿼리에 대해서는 로우의 모든 데이터가 필요하지 않다.

   • 이 경우 읽어야 하는 데이터(I/O)가 줄어든다. → 쿼리 성능 향상 및 리소스 절약 가능.

2. 높은 압축률

   • 유사한 데이터가 같은 컬럼에 모여 있으므로, 압축하기에 용이하다. → row 단위보다 column 단위가 압축률이 더 우수하다.
   • 컬럼에 저장된 데이터의 특성에 기반하여 delta compression, prefix compression 등과 같은 특화된 압축 알고리즘을 선택하면, 압축 효율을 더욱 높일 수 있다.
   • 압축 비율이 높다는 것은, 같은 데이터 양을 전송하거나 저장할 때 필요한 대역폭과 저장 공간을 더 효율적으로 사용할 수 있다.

Delta Compression(델타 압축)은 값 자체를 모두 저장하는 대신, 이전 값과의 차이(Delta)만 저장하는 방식이다. 주로 숫자나 시간처럼 순차적으로 증가하는 값에 효과적이고, 작은 차이만 기록하면 되므로 저장 공간을 크게 줄일 수 있다.

Prefix Compression(접두사 압축)은 문자열 값에서 앞부분의 공통된 접두사(prefix)를 한 번만 저장하고, 매번 달라지는 뒷부분만 별도로 저장하는 방식이다. 예를 들어 customer_100, customer_101처럼 앞부분이 반복되는 문자열에 특히 유용하다.
이런 특화된 알고리즘을 사용하면 더 향상된 압축비율을 얻을 수 있다는 말을 하고싶은 거임.

1.2.2 Consistency Model

RDBMS는 전통적으로 ACID(Atomicity, Consistency, Isolation, Durability)를 강력히 보장한다.
하지만 분산형 NoSQL 시스템에서는 확장성(Scalability)과 가용성(Availability)을 중시하기 때문에, 완벽한 일관성을 유지하기가 어렵다. 특히 여러 노드에 데이터가 분산 저장되는 환경에서는 Consistency(일관성)을 완화해야 하는 경우가 많다.

분산 시스템의 일관성 모델은 다음과 같이 여러 수준으로 나눌 수 있다:

• Strict: Atomicity, immediately
• Sequential: 순서는 보장한다.
• Causal: 인과적으로 연결된 변경사항에 한해 모든 클라이언트가 순서대로 동일하게 바라본다.
• Eventual: 어느정도 시간이 지나면 결국에는 모두 반영이 된다. 순서나 인과보장X.
• Weak: 모든 갱신 내역이 전파되리라는 보장도 없고, 갱신 사항이 각 클라이언트에서 뒤죽박죽 섞여 표시될 수 있다.

1.2.3 CAP Theory

분산 시스템은 세 가지 요소, 일관성(consistency), 가용성(availability), 분할 허용성(tolerance to network paritions) 중에서 두 개 까지만 달성할 수 있다는 이론이다.

• 즉, 분산시스템은 일관성과 가용성을 동시에 성취할 수 없다.

1.2.4 기준

NoSQL 데이터베이스를 선택할 때의 기준

1. 데이터모델: key-value(most of NoSQL), semistructured(MongoDB), column-oriented(HBase), document-oriented(ElasticSearch)
2. 저장모델: inmemory, persistent
   • 우리가 고민하는 대상은 persistent다.
3. 일관성 모델: 위에 consistency model
   • 이는 수확(harvest) 및 산출(yield)로서 측정되기도 한다.- https://people.eecs.berkeley.edu/~brewer/Giant.pdf
4. 물리적 모델
   • 장치의 분산, 단일. 클라이언트가 어느 수준까지 코딩해야하는 지.
5. 읽기/쓰기 성능
6. 보조 색인(secondary index)
   • 보조색인 기능이 없을 때, 애플이케이션에서 대처하거나 보조 색인을 자체적으로 emulate 할 수 있는가?
7. 장애 처리
8. 압축
   • 어느 비율? custom plugin?
9. 부하 분산
10. 원자적 읽기, 갱신, 쓰기 (+ 어느 단위로 되는지 개별레코드/테이블/클러스터 단위)
    1. 멀티스레드 또는 비공유(shared nothing) 애플리케이션 서버 구조에서 race condition을 예방할 수 있다.
    2. compare and swap(CAS) or check and set 가능?
    3. 클라이언트의 복잡도를 줄일 수 있다.
11. 락 걸기, 대기, 데드락

• 어떤 유형의 락 모델을 지원하는가? 이것은 데드락을 유발할 수 있는가?
• 대부분의 NoSQL은 락을 포기하는 방식을 사용한다.

실제적으로는 많은 데이터베이스들이 Atomic에 대한 기능을 좀 더 확대하는 쪽으로 가고 락 기능을 추가하기 위해서 고려하지는 않는다. 어떻게 하면 락을 최소화할까에 대한 고민을 많이 하는 편.

💡 impedance match: 모든 문제에 두루 적용되는 접근 방식을 사용하기보다는 달리 사용 가능한 솔루션이 있는지 알아보아야 한다.
현재 겪고 있는 문제를 가장 잘 해결해줄 수 있는 시스템을 사용하자.

1.2.5 확장성

RDBMS에서 고민이 되는 시점. 데이터 양이 많아졌을 때,

• 성능을 위해서 관계형 기반 기능을 아예 없애버리는 것이 좋지 않을까 하는 것.
• 데이터 모델을 비정규화(denormalization)해서 불필요한 락 걸기 최소화함으로 락 거는 시간과 데드락 없애볼까
• 데이터 많아져도 파티션 재분배 필요 없는 수평적 확장 방식은 어떨까?
• 확장한 구조를 이용해서 결함 허용성과 데이터 가용성을 얻을 수 있을까?

위 고민들이 결국 HBase를 만들게 됨.

1.2.6 데이터베이스 (비)정규화

확장된 환경에서 스키마를 다르게 설계하는 일이 필수적일 때 - DDL

• 비정규화(denormalization)
  • 데이터를 두 개 이상의 테이블에 복제하여 스키마를 비정규화 하는 개념.
    • 읽기를 수행할 때 추가적으로 데이터를 취합할 필요가 없다.
    • 요구되는 view를 위한 구체화 작업을 사전에 수행 → 최적화 가능
• 복제(duplication)
• 인텔리전트 키(intelligent keys)