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)

• Named Lock과 다른 동시성 제어 방법들의 차이점은 무엇인가요?
• Named Lock을 사용할 때 주의해야 할 부하 관련 이슈는 무엇인가요?

✅ Named Lock은 이름 기반의 잠금 메커니즘으로, 특정 문자열을 키로 사용하여 동시성을 제어하는 방법입니다. MySQL의 GET_LOCK(), RELEASE_LOCK() 함수를 통해 사용할 수 있습니다.

• 사용법

  • 획득: SELECT GET_LOCK('lock_name', timeout)
  • 해제: SELECT RELEASE_LOCK('lock_name')
  • 확인: SELECT IS_FREE_LOCK('lock_name')
  • 예시 코드:

  -- Lock 획득 (10초 타임아웃)
  SELECT GET_LOCK('order_process_12345', 10);
   
  -- 비즈니스 로직 수행
  UPDATE orders SET status = 'processing' WHERE id = 12345;
   
  -- Lock 해제
  SELECT RELEASE_LOCK('order_process_12345');

• 장점

  • 🎯 유연한 잠금 범위: 테이블/행 단위가 아닌 비즈니스 로직 단위로 잠금 가능
  • ⚡ 빠른 성능: 메모리 기반으로 동작하여 디스크 I/O 없이 빠른 처리
  • 🔧 간단한 구현: 별도의 인프라 없이 MySQL 함수만으로 구현 가능
  • 🌐 분산 환경 지원: 여러 애플리케이션 서버에서 동일한 MySQL을 통해 동시성 제어

• 단점

  • ⚠️ 수동 관리 필요: 개발자가 직접 Lock 획득/해제를 관리해야 함
  • 🔗 Connection 종속성: Connection이 끊어지면 자동으로 Lock이 해제됨
  • 📊 제한된 모니터링: Lock 상태를 추적하고 디버깅하기 어려움
  • 💾 메모리 사용: 많은 Lock 사용 시 MySQL 메모리 사용량 증가

• 부하 관련 이슈

  • Connection Pool 고갈: Lock을 오래 보유하면 Connection이 부족해질 수 있음
  • Lock 대기 증가: 타임아웃 설정이 길면 대기 스레드가 늘어나 성능 저하
  • 메모리 압박: 동시에 많은 Named Lock 사용 시 MySQL 메모리 부담
  • 모니터링 어려움: 어떤 프로세스가 Lock을 보유 중인지 추적 곤란

• 대체 동시성 제어 장치

  • Pessimistic Lock (비관적 잠금)
    • DB 레벨에서 SELECT ... FOR UPDATE 사용
    • 트랜잭션 내에서만 유효
  • Optimistic Lock (낙관적 잠금)
    • Version 컬럼을 이용한 충돌 감지
    • 동시 수정이 적은 경우 효율적
  • Redis 분산 락
    • Redlock, Redisson 등 사용
    • 별도 인프라 필요하지만 더 강력한 기능
  • ZooKeeper
    • 강력한 분산 조정 서비스
    • 복잡하지만 안정적인 동시성 제어

• 꼬리질문: Named Lock과 다른 동시성 제어 방법들의 차이점은 무엇인가요?

  • Pessimistic Lock과의 차이
    • Named Lock: 애플리케이션 레벨, 이름 기반, Connection 종속
    • Pessimistic Lock: DB 레벨, 행/테이블 기반, 트랜잭션 종속
  • Optimistic Lock과의 차이
    • Named Lock: 사전 차단 방식, Lock 대기 발생
    • Optimistic Lock: 충돌 감지 방식, 재시도 로직 필요
  • Redis Lock과의 차이
    • Named Lock: MySQL 내장, 추가 인프라 불필요
    • Redis Lock: 별도 Redis 필요, TTL 지원, 더 많은 기능

• 꼬리질문: Named Lock을 사용할 때 주의해야 할 부하 관련 이슈는 무엇인가요?

  • Connection Pool 관리
    • Lock 보유 시간 최소화 필요
    • Pool 크기 적절히 설정 (Lock 대기 Connection 고려)
  • 타임아웃 설정
    • 너무 길면: 대기 스레드 증가로 시스템 부하
    • 너무 짧으면: Lock 획득 실패로 재시도 증가
    • 권장: 비즈니스 로직 수행 시간의 2-3배
  • Lock 이름 관리
    • 너무 세분화: 메모리 사용량 증가
    • 너무 광범위: Lock 경합 증가
    • 권장: 적절한 단위로 그룹핑 (예: order_lock_{user_id % 100})
  • 모니터링 구현
    • Lock 획득/해제 로깅
    • 장시간 Lock 보유 감지
    • Connection Pool 사용률 모니터링

• Union은 왜 중복을 제거하나요?
• Union All이 Union보다 빠른 이유는 무엇인가요?

✅ UNION은 두 개 이상의 SELECT 문의 결과를 결합하면서 중복된 행을 제거하는 반면, UNION ALL은 중복을 제거하지 않고 모든 결과를 그대로 반환합니다.

• UNION

  • 📜 기능: 여러 SELECT 문의 결과를 합칩니다.
  • 🗑️ 중복 제거: 결과 집합에서 중복된 행을 자동으로 제거합니다.
  • 🐢 성능: 중복을 찾기 위해 내부적으로 정렬(Sort) 또는 해시(Hash) 작업을 수행하므로 UNION ALL보다 느립니다.
  • 🤔 언제 사용?: 순수한 합집합(Set Union)이 필요할 때, 즉 중복이 없는 유니크한 결과만 원할 때 사용합니다.

• UNION ALL

  • 📜 기능: 여러 SELECT 문의 결과를 합칩니다.
  • ✨ 중복 허용: 중복된 행을 포함하여 모든 결과를 그대로 반환합니다.
  • 🚀 성능: 중복 제거 과정이 없으므로 UNION보다 훨씬 빠릅니다.
  • 🤔 언제 사용?: 중복된 결과가 상관없거나, 중복이 발생하지 않을 것이 확실할 때 성능상의 이점을 위해 사용합니다.

• 예시 코드

  -- table_a: (1, 'A'), (2, 'B'), (3, 'C')
  -- table_b: (3, 'C'), (4, 'D'), (5, 'E')
   
  -- UNION (중복 '3, C'가 제거됨)
  SELECT * FROM table_a
  UNION
  SELECT * FROM table_b;
  -- 결과: (1, 'A'), (2, 'B'), (3, 'C'), (4, 'D'), (5, 'E')
   
  -- UNION ALL (중복 '3, C'가 포함됨)
  SELECT * FROM table_a
  UNION ALL
  SELECT * FROM table_b;
  -- 결과: (1, 'A'), (2, 'B'), (3, 'C'), (3, 'C'), (4, 'D'), (5, 'E')

• 꼬리질문: Union은 왜 중복을 제거하나요?

  • UNION은 관계대수(Relational Algebra)의 합집합(Set Union) 연산에 기반을 두고 있기 때문입니다. 집합 이론에서 합집합은 중복된 원소를 포함하지 않는 것이 기본 원칙입니다. 따라서 SQL의 UNION도 이 원칙을 따라 중복을 제거합니다.

• 꼬리질문: Union All이 Union보다 빠른 이유는 무엇인가요?

  • UNION ALL은 단순히 두 결과 집합을 위아래로 붙이기만 하는 반면, UNION은 중복을 제거하기 위해 추가적인 작업을 수행해야 합니다.
  • 이 추가 작업은 보통 결과 집합을 정렬(Sorting)하거나 해시 테이블(Hash Table)을 만들어 중복 여부를 검사하는 과정이며, 이로 인해 상당한 오버헤드가 발생합니다. 따라서 UNION ALL이 훨씬 빠릅니다.