Data Partitioning Basics

Data Partitioning 은 db를 많은 작은 파트로 쪼개는 기술이다. 이로써 manageability, 퍼포먼스, 가용성, 그리고, 어플리케이션의 로드밸런싱을 개선시켜준다.

• Partitioning Method 의 종류
  • Horizontal Partitioning: put diff rows into diff tables. 다른 row 들을 다른 테이블로 놓는다. 즉, 테이블에 row가 적재되는 매트릭스를 생각할 때, 이를 가로로 자른다고 생각하면 된다. 이러한 파티셔닝은 또한 Data Sharding이라고도 얘기함
    • 단점으로는 이러한 파티셔닝을 하기 위한 범위를 신중하게 설정하지 않으면, 파티셔닝 스키마는 언밸런스한 서버가 될 것이다.(즉, 균일하게 쪼개지지 않았다는 얘기다.)
  • Vertical Partitioning:
    • 특정 피쳐에 맞게 데이터를 쪼개서 다양한 테이블에 저장하는걸 얘기한다. 가령 인스타그램은 유저, 포토, 그들이 follow하는 사람 등을 다른 테이블로 만들어 적재함
      • 장점: straightforward to implement, a low impact on the application
  • Directory Based Partitioning
    • 디렉토리 서버가 db 서버들 앞단에 위치하여, 각 db 서버들은 고유 키 값으로 디렉토리 서버를 통해 맵핑됨. 즉 우리는 directory 서버에 쿼리를 날리고, 디렉토리 서버는 매핑되는 key를 이용해 알맞은 db서버에 쿼리를 날린다.
      • 장점은 db pool에 서버 등을 추가하거나, 스킴을 파티셔닝할 때 애플리케이션에 지장을 주지 않으면서 작업을 할 수 있음
• Partitioning Criteria(파티셔닝을 하는 규칙들)
  • Key or Hash-based Partitioning: db 데이터의 key attribute를 하나 잡아서 이에 해쉬 함수를 적용하는 것이다. 예로들면, 100 개의 db서버가 있다고 할 때, data 의 id값이 생성될 때마다 1씩 증가하는 규칙을 따른다고 하자. 그럼 이 id를 key attribute 로 할 때 %100 을 해쉬 연산으로 하면, 100개에 고르게 분산될 수 있을 것이다.
  • List Partitioning: 리스트 파티셔닝에서 각 파티션은 벨류들의 리스트에 할당된다. 그래서 우리가 새로운 record를 insert할 때, 우리는 어떤 파티션이 key를 갖고 있는지 찾아야 하고, 그 키를 갖고 있는 파티션에 데이터를 삽입할 것이다. 예로 들면, Iceland, Norway, Swden 등의 데이터는 Nordic countries라는 리스트 네임을 가진 파티션에 저장될 것임
  • Round Robin Partitioning: uniform data Distribution을 보장하는 매우 심플한 방식임. With ’n’ partitions -> ‘k’ tuple is assigned to partition k mod n.
  • Composite Partitioning: 위의 것들을 적재적소에 결한한 파티셔닝 방식임. 예로 들면, list partitioning scheme 적용 이후 -> hash-based Partitioning을 그다음 적용할 수 있음. 그러면 list partitioning은 key space 를 줄여주는 효과를 낸다.
• Common Problems of Data Partitioning
  • Joins and Denormalization: 파티셔닝으로 인해 data들이 분산되있는 경우, join 연산을 할 때, 데이터들이 여러 서버로부터 컴파일 되기 때문에 퍼포먼스가 떨어질 수 있다. 이러한 해결책은 데이터베이스를 비정규화 하여 사전에 join 연산이 필요한 쿼리가 싱글 테이블로부터 작동할 수 있게 해주는 것이다. 물론, 데이터 비정규화로 비롯된 데이터 불일치 등의 위험은 감수해야한다.
  • Referential Integrity(참조/관계에 있는 테이블 간 통합 문제): 외래키와 같은 방식으로 테이블 통합을 할 때, 파티셔닝된 데이터베이스로는 매우 어렵다. (대부분의 RDBMS 는 다른 db 서버들간 외래키 지원에 제약이 있음)
  • Rebalancing(리밸런싱 문제): 파티셔닝 스킴을 바꿔줘야 하는 문제가 생긴다. 왜 파티셔닝 스킴을 바꿔줘야하는지 이유는 아래와 같다.
    • Data 분산이 균일하지 않을 수 있음
    • 파티션에 너무 많은 로드가 걸리는 경우: 예로 들면, user photos와 관련된 db파티션에서 많은 요청이 발생한다고 가정해보자. 이러한 경우에, 우리는 db 파티션을 더 많들거나, 기존에 존재하는 파티션을 리밸런싱할 수 있다. 이걸 더 구체적으로 얘기하면, 파티셔닝 스킴을 바꾸고, 모든 존재하는 데이터를 새로운 장소로 이동시키는 것을 말하는데, 다운타임 없이 이걸 하는건 엄청 어려움..