2번 상황이 더 적절하다. lock을 얻기 전에 transaction을 시작해버리면 connection pool이 낭비될 수 있기 때문이다.

• https://dev.mysql.com/doc/refman/8.4/en/bit-functions.html (opens in a new tab)

행기반 데이터베이스는 데이터를 메모리에서 행 단위로 연속적으로 저장해, 빠른 읽기/쓰기가 필요한 트랜잭션 처리(OLTP)에 유리합니다. 반면 열기반 데이터베이스는 데이터를 열 단위로 저장해, 분석 쿼리(OLAP)에서 필요한 열만 빠르게 읽을 수 있고, 압축 효율성이 좋습니다. 열기반은 대용량 분석에 적합하지만, 행기반은 트랜잭션 처리에 더 효과적입니다.

1. 행(Row)기반 데이터베이스

• 특징

  • 저장 구조: 데이터의 각 행(row)을 단위로 연속된 공간에 저장합니다. 즉, 한 행에 포함된 모든 컬럼 값들이 함께 저장됩니다.
  • 사용 패턴: 한 번에 전체 행의 데이터를 읽거나 쓰는 경우가 많으며, OLTP(Online Transaction Processing)와 같이 빈번한 쓰기 작업, 레코드 단위의 조작이 중요한 환경에서 주로 사용됩니다.

• 장점

  • 빠른 트랜잭션 처리: 한 레코드에 대한 읽기 및 쓰기 작업이 한 번에 이루어지므로, INSERT, UPDATE, DELETE와 같은 트랜잭션 처리에서 빠른 성능을 보입니다.
  • 단순한 데이터 접근: 레코드 단위로 데이터를 다루므로, 응용 프로그램에서 데이터를 가져오거나 수정할 때 직관적입니다.
  • 복잡한 트랜잭션 지원: ACID 특성을 잘 지원하여 복잡한 트랜잭션 환경에서 안정적인 성능을 보장합니다.

• 단점

  • 분석 쿼리 비효율: 특정 컬럼에 대한 집계나 분석을 수행할 때, 필요한 컬럼만 읽어오는 것이 어렵고 전체 행을 읽어야 하므로 I/O 비용이 증가합니다.
  • 캐시 활용의 한계: 필요한 데이터만 추출하기 어려워, 메모리 캐시에 불필요한 데이터까지 적재되는 경우가 발생할 수 있습니다.

2. 열(Column)기반 데이터베이스

• 특징

  • 저장 구조: 데이터의 각 컬럼(column)을 단위로 연속된 공간에 저장합니다. 즉, 동일 컬럼의 값들이 연속해서 저장됩니다.
  • 사용 패턴: 대규모 데이터 분석, 집계, 리포팅 등 OLAP(Online Analytical Processing) 환경에서 주로 사용되며, 특정 컬럼만 선택하여 빠르게 읽어들일 수 있습니다.

• 장점

  • 빠른 분석 쿼리 성능: 필요한 컬럼만 읽어오기 때문에 I/O 오버헤드가 줄어들고, 대량의 데이터를 빠르게 처리할 수 있습니다.
  • 효율적인 압축: 동일 데이터 타입의 값들이 연속되어 저장되므로, 압축률이 높아 저장 공간을 절약할 수 있습니다.
  • 벡터화 처리 지원: 대량의 데이터를 한 번에 처리하는 벡터화 연산에 유리하여, 병렬 처리 및 최적화된 분석 쿼리를 구현할 수 있습니다.

• 단점

  • 트랜잭션 처리에 부적합: 레코드 단위의 빠른 쓰기 작업이 필요한 OLTP 환경에서는 오히려 성능이 저하될 수 있습니다. 개별 행을 재구성해야 하는 작업이 비효율적입니다.
  • 데이터 업데이트 비용: 행 전체를 업데이트하는 대신 여러 컬럼에 분산되어 저장되어 있기 때문에, 한 행에 대한 업데이트 시 여러 영역을 수정해야 하여 비용이 발생할 수 있습니다.
  • 구조 설계 복잡성: 데이터가 컬럼 단위로 분리되어 있으므로, 행 간 연관성을 고려한 쿼리를 작성하거나 조인 등의 작업 시 복잡도가 증가할 수 있습니다.

• 사딩은 크게 수직 분할과 수평 분할로 나눔

1. 수직 분할 한 스키마에 저장되어 있는 데이터를 특정 칼럼 단위로 잘라내어 분할 저장합니다. 수직 파티셔닝은 각 스키마를 나누고 데이터가 따라 옮겨갑니다.

결국 논리적 엔티티들을 다른 물리 엔티티들로 나누는 것을 의미합니다.

2. 수평 분할 한 스키마에 저장되어 있는 데이터를 특정 알고리즘을 통해 행 단위로 잘라내어 분할 저장합니다. 수평 분할은 하나로 구성된 스키마를 동일한 구성의 여러 개의 스키마로 분리한 후, 각 스키마에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리합니다.

• 샤딩 알고리즘

수평 분할을 통한 샤딩은 샤딩 알고리즘이 필요합니다. 기준이 되는 샤드키를 통해 어느 스키마에 접근하여 데이터를 핸들링할 것인지 정해야 하기 때문입니다. 한마디로 라우팅을 위한 알고리즘입니다.

1. Modular Sharding

장점: Range 샤딩에 비해 데이터가 균일하게 분산됩니다. 단점: DB를 추가 증설하게 된다면 이미 적재된 데이터들의 재정렬이 필요합니다. (ex) (DB는 2개, 상품번호가 0~10까지 있을 경우) 상품번호 % 2 모듈러 연산 시 DB1에는 0,2,4,6,8,10 상품, DB2에는 1,3,5,7,9 상품이 들어가게 됩니다. Modular 샤딩은 데이터량이 일정 수준에서 유지될 것으로 예상되는 데이터 성격을 가진 곳에 적용할 때 어울리는 방식입니다.

실제적으로 상품 데이터를 적재하고 있으나, 해당 데이터는 장기적으로 미사용 할 경우 다른 디비에 옮겨 보관하기 때문에 적합합니다. 데이터가 꾸준히 늘어나더라도 적재속도가 그리 빠르지 않다면 문제없다고 합니다.

일단 데이터가 균일하게 분산된다는 점 자체가 트래픽을 안전하게 소화하면서도 DB 리소스를 최대한 활용할 수 있기 때문입니다.

2. Range Sharding

Range 샤딩은 샤드키의 범위를 기준으로 DB를 선택하는 방식입니다.

장점: Modular 샤딩에 비해 증설에 재정렬 비용이 들지 않습니다. 단점: 일부 DB에 데이터가 몰릴 수 있습니다. Range 샤딩은 증설작업에 드는 비용이 크지 않습니다. Modular의 경우 증설작업이 진행될 경우 기존 데이터들도 모두 재정렬을 해야 합니다. 이런 부분에서 편합니다.

하지만 많이 접근하는 데이터가 있는 DB 쪽으로 트래픽이나 데이터량이 몰릴 수 있습니다. 결국 샤딩을 했더라도 동일한 현상이 나타난다면 또 부하 분산을 통해 DB를 쪼개 재정렬하는 작업이 필요하고, 반대로 트래픽이 저조한 DB는 통합 작업을 통해 유지비용을 아끼도록 관리해야 합니다.

• Reference : Gmarket Tech 샤딩이란 무엇인가 (opens in a new tab)