Skip to main content
이 문서는 Lakebase 섹션의 일부입니다.

1. 왜 Lakebase에서 최적화가 중요한가

OLTP vs OLAP 특성 차이

Databricks는 본래 대규모 분석(OLAP, Online Analytical Processing) 워크로드에 최적화된 플랫폼입니다. Lakebase는 그 위에 OLTP (Online Transaction Processing) 특성을 더한 관리형 PostgreSQL로, 두 세계를 연결하는 역할을 합니다.

Databricks 관리형이라는 특징

Lakebase는 단순한 PostgreSQL이 아니라 Databricks Unity Catalog 아래에서 동작하는 관리형 서비스입니다. 이 때문에 다음과 같은 제약과 이점이 동시에 존재합니다.
  • 이점: 자동 백업, Unity Catalog 거버넌스, Delta 테이블과의 양방향 동기화 (Synced Tables)
  • 제약: 직접 OS/스토리지 레벨 접근 불가, pg_hba.conf 등 일부 서버 파라미터 변경 제한
  • 네트워크: Databricks Apps와 동일 VPC 내에서 Private Link로 저지연 통신
따라서 최적화 전략은 “PostgreSQL 표준 방법”을 기반으로 하되, 관리형 환경의 제약을 인식하고 적용 해야 합니다.
참고: Databricks Lakebase 공식 문서

2. CRUD 작업 패턴

INSERT — 삽입 최적화

단건 INSERT는 네트워크 왕복(round-trip)이 발생할 때마다 오버헤드가 누적됩니다. 배치 처리 (batch insert) 를 활용하면 성능을 크게 향상시킬 수 있습니다.

SELECT — 조회 최적화

UPDATE — 수정 최적화

DELETE — 삭제 최적화


3. 인덱스 전략

PostgreSQL 인덱스 유형

인덱스 설계 가이드

인덱스가 많을수록 INSERT/UPDATE/DELETE 속도가 저하됩니다. 쿼리 패턴을 먼저 분석하고 필요한 인덱스만 생성하십시오.

4. 연결 관리 (Connection Management)

Connection Pooling의 필요성

PostgreSQL은 연결(connection)마다 별도 프로세스를 생성합니다. Databricks Apps처럼 다수의 요청이 동시에 들어오는 환경에서는 커넥션 풀링 (connection pooling) 이 필수입니다.

Databricks Apps에서의 연결 패턴

Databricks Apps는 기본적으로 단일 프로세스 내에서 실행됩니다. 아래 원칙을 따르십시오.
  • @st.cache_resource 로 연결 풀을 앱 수명 동안 한 번만 생성
  • 요청마다 연결을 생성/소멸하지 않음 (오버헤드 발생)
  • Lakebase 연결 수 상한 은 인스턴스 크기에 따라 다르며, 기본적으로 수백 개 수준
  • 연결이 오래 유휴 상태로 남으면 서버 측에서 끊길 수 있으므로 pool_pre_ping=True 권장
참고: PostgreSQL Connection Pooling Best Practices

5. 데이터 동기화 — Delta ↔ Lakebase (Synced Tables)

Synced Tables 개요

Synced Tables 는 Delta 테이블의 데이터를 Lakebase PostgreSQL 테이블로 자동 동기화하는 기능입니다. 분석용 데이터(Delta)를 OLTP 앱(Lakebase)에서 빠르게 조회할 수 있도록 연결해 줍니다.

Synced Tables 생성

실시간 vs 배치 동기화 비교

참고: Databricks Synced Tables 문서

6. 성능 튜닝

쿼리 실행 계획 분석 (EXPLAIN)

실행 계획에서 주의해야 할 키워드:
  • Seq Scan — 인덱스 미사용, 풀 스캔 → 인덱스 추가 검토
  • Nested Loop — 작은 결과셋에 유리, 대용량에는 Hash Join이 나을 수 있음
  • cost=... — 예상 비용 (rows, width 포함)
  • actual time=... — 실제 소요 시간 (ms)

파티셔닝 (Partitioning)

시계열 데이터나 수억 건 이상의 대형 테이블에는 테이블 파티셔닝 (table partitioning) 을 적용합니다.

벌크 로드 최적화


7. 장단점과 트레이드오프

Lakebase vs 직접 RDS 운영

비용 고려사항

  • Lakebase는 DBU (Databricks Unit) 기반으로 과금되므로, 항상 켜두는 OLTP DB로 사용 시 비용이 누적됩니다.
  • 트래픽이 낮은 시간대에 자동 일시 중지 (auto-pause) 설정을 활용하십시오.
  • Synced Tables는 동기화 빈도에 따라 추가 연산 비용이 발생합니다.

8. 베스트 프랙티스와 흔한 실수

베스트 프랙티스

흔한 실수


전체 CRUD 앱 예제: 고객 관리 시스템

아래는 위 모든 원칙을 적용한 완전한 Streamlit CRUD 앱입니다.

참고 자료