52P by xguru 13일전 | favorite | 댓글 13개
  • 다양한 문제를 해결하기 위해 주목할 가치가 있는 DB 7개를 소개
  • 이는 "최고의 DB" 목록이 아닌, 새롭고 유용한 관점을 제공하는 도구들
  • 2025년엔 이들 각 DB에 대해 일주일씩 투자해보길 바람(7 DBs in 7 Weeks)

1. PostgreSQL: 기본 데이터베이스

  • PostgreSQL은 기본적으로 사용되는 안정적인 기술
    • "Just use Postgres"라는 문구는 널리 알려진 밈이자 신뢰성을 상징하는 표현임
    • ACID를 준수하며 물리적 및 논리적 복제를 포함한 강력한 기능을 제공함
    • 주요 벤더들 간에 광범위한 지원을 받고 있는 안정적 데이터베이스임
  • PostgreSQL의 가장 큰 매력: 확장성
    • 확장 기능(Extensions)을 통해 독창적인 기능을 추가 가능함
    • 주요 확장 기능 예시:
      • AGE: 그래프 데이터 구조와 Cypher 쿼리 언어 지원
      • TimescaleDB: 시계열 데이터 작업 지원
      • Hydra Columnar: 열 기반 스토리지 엔진 제공
    • 확장 기능은 PostgreSQL을 타 데이터베이스와 차별화시키는 핵심 요소임
  • PostgreSQL의 유용성과 확장성
    • 다양한 생태계를 갖추고 있으며, 기본 설정이 합리적이고 사용자 친화적임
    • 비 PostgreSQL 서비스에서도 Postgres 와이어 프로토콜을 사용해 클라이언트 호환성을 제공함
    • WebAssembly(Wasm) 환경에서도 설치 가능할 정도로 가벼움
  • PostgreSQL 학습 권장
    • PostgreSQL의 가능성과 한계를 이해하기 위해 시간을 투자할 가치가 있음
    • 예: MVCC(Multi-Version Concurrency Control)의 복잡성 이해
    • 간단한 CRUD 애플리케이션 개발, PostgreSQL 확장 기능 작성 등을 추천함

2. SQLite: 로컬-우선 데이터베이스

  • SQLite는 "로컬 우선" 데이터베이스로 독립적으로 실행 가능
    • 클라이언트-서버 모델을 벗어나 애플리케이션과 같은 환경에서 실행됨
    • 예시: WhatsApp과 Signal은 기기 내부에 SQLite를 사용하여 채팅 데이터를 저장함
  • SQLite의 발전된 활용 사례
    • 기본 ACID 준수 데이터베이스 이상의 창의적인 사용 가능
    • 새로운 도구와 확장 기능:
      • Litestream: SQLite의 스트리밍 백업 제공
      • LiteFS: 분산 액세스를 지원하여 더욱 유연한 토폴로지 구현
      • CR-SQLite: CRDT(Conflict-free Replicated Data Types)를 사용해 변경 세트를 병합할 때 충돌 해결 필요성을 제거
  • SQLite의 인기 재조명
    • Ruby on Rails 8.0 덕분에 다시 주목받고 있음
    • 37signals: SQLite를 기반으로 Rails 모듈(Solid Queue 등)을 개발
      • Rails의 다중 SQLite 데이터베이스 관리 지원 (database.yml)
    • Bluesky: 개인 데이터 서버(Personal Data Servers)로 사용자마다 개별 SQLite 데이터베이스 사용
  • SQLite 활용 학습 권장
    • SQLite를 이용한 로컬 중심 아키텍처 실험
    • 기존의 PostgreSQL 기반 클라이언트-서버 모델을 SQLite로 대체할 수 있는지 시도

3. DuckDB: 모든 것을 질의할 수 있는 데이터베이스

  • DuckDB는 OLAP에 특화된 임베디드 데이터베이스
    • SQLite처럼 애플리케이션과 함께 작동하지만 OLTP 대신 OLAP 작업에 중점
    • 데이터 분석 및 쿼리 중심으로 설계된 시스템
  • DuckDB의 "쿼리-애니씽(Query-Anything)" 특성
    • 다양한 데이터 소스를 직접 SQL로 쿼리 가능:
      • CSV, TSV, JSON 등 일반 파일 형식
      • Parquet 등 고급 파일 형식 지원
    • 이 기능은 유연성을 제공하며, 예: Bluesky의 데이터 스트림 분석
  • 확장성 및 생태계
    • DuckDB에도 확장 기능이 존재하나, Postgres만큼 풍부하지 않음 (상대적으로 젊은 프로젝트)
    • 커뮤니티 기여 확장이 많이 있으며, gsheets(Google Sheets 연동)가 주목할 만함
  • DuckDB 활용 학습 권장
    • Python 노트북이나 Evidence를 통해 데이터 분석 및 처리 실험
    • SQLite와 결합: SQLite 데이터베이스의 분석 쿼리를 DuckDB로 위임해 성능 향상

4. ClickHouse: 컬럼형 데이터베이스

  • ClickHouse는 OLAP 작업에 특화된 데이터베이스
    • OLTP는 PostgreSQL, OLAP는 ClickHouse라는 조합이 이상적임
    • 대규모 분석 워크로드를 처리하며, 수평 확장과 샤딩을 통해 높은 데이터 삽입 속도를 지원함
  • ClickHouse의 주요 특징
    • 계층형 스토리지 지원:
      • "핫 데이터"와 "콜드 데이터"를 분리해 저장 가능
      • 예: GitLab 문서에서 이를 활용한 사례를 자세히 다룸
    • 대규모 데이터셋 처리 및 실시간 분석:
      • DuckDB로는 처리하기 어려운 크기의 데이터셋에 적합
      • 실시간 분석이 필요한 상황에서 강력한 성능 제공
  • 운영의 편리함
    • 배포, 확장, 백업 등 운영 관련 문서가 체계적이며 상세함
    • 예: 적절한 CPU 설정 방법까지 다룬 문서 제공
  • ClickHouse 학습 권장
    • 대규모 분석 데이터셋 실험 또는 DuckDB로 작업한 분석을 ClickHouse로 변환
    • ClickHouse의 임베디드 버전인 chDB를 활용해 SQLite와 더 직접적으로 비교 가능

5. FoundationDB: 레이어드 데이터베이스

  • FoundationDB는 "데이터베이스의 기반" 역할을 하는 독특한 시스템
    • 키-값 저장소로 설계되었으나 단순한 데이터베이스라기보다는 데이터베이스를 구축하는 "기초"로 작동
    • 애플, Snowflake, Tigris Data와 같은 주요 기업에서 사용
  • 주요 특징 및 한계
    • 제한사항:
      • 트랜잭션 데이터는 10MB를 초과할 수 없음
      • 트랜잭션은 첫 번째 읽기 이후 5초를 넘길 수 없음
    • 이러한 제한으로 인해 대규모 환경에서도 완전한 ACID 트랜잭션 지원 가능
      • 예: 100TiB 이상의 클러스터 운영 사례
  • FoundationDB의 설계와 테스트
    • 특정 워크로드에 최적화되어 설계됨
    • 시뮬레이션 테스트를 통해 안정성과 확장성을 입증:
      • Antithesis 및 다른 데이터베이스에서도 동일한 테스트 방법론 사용
      • 관련 참고 자료: Tyler Neely와 Phil Eaton의 문서
  • "레이어드" 데이터베이스로서의 FoundationDB
    • 스토리지 엔진과 데이터 모델 간 결합이 느슨함:
      • 다양한 레이어에서 스토리지 엔진을 재매핑 가능
      • 예: Record 레이어, Document 레이어 (FoundationDB 조직에서 제공)
    • Tigris Data에서 작성한 레이어 설계 사례가 참고할 만함
  • FoundationDB 학습 권장
    • 튜토리얼을 진행하며 RocksDB 같은 시스템을 대체할 가능성 탐색
    • 설계 방법(Design Recipes)과 관련 논문 읽기
    • Anti-Features와 Features 문서를 통해 사용 제한과 해결 가능한 문제 이해

6. TigerBeetle: 철저하게 정확한 데이터베이스

  • TigerBeetle는 금융 트랜잭션에 특화된 단일 목적 데이터베이스
    • 범용 데이터베이스와 달리 특정 목적, 특히 금융 거래에 초점
    • 오픈 소스로 제공되며, 높은 수준의 신뢰성과 정확성을 목표로 설계
  • 철저한 정확성을 위한 설계 철학
    • NASA의 Power of Ten Rules프로토콜 인지 복구(Protocol-Aware Recovery) 구현
    • 엄격한 직렬화(strict serialisability)Direct I/O 사용으로 커널 페이지 캐시 관련 문제 회피
    • 안전성 문서(Safety doc)와 독특한 프로그래밍 방식 "Tiger Style"에서 철저함을 확인 가능
  • Zig 언어로 구현된 혁신적 접근
    • Zig는 시스템 프로그래밍 언어로 비교적 신생이지만, TigerBeetle의 목표에 이상적으로 부합
    • 간결성과 성능을 극대화하는 데 Zig의 장점을 활용
  • TigerBeetle 학습 및 활용 제안
    • 로컬 배포 환경에서 금융 계좌 모델링 실험:
      • Quick Start를 따라 설치 및 사용
    • 시스템 아키텍처 문서(System Architecture docs)를 참고하여 범용 데이터베이스와 결합 가능성 탐구
    • 예: PostgreSQL 또는 FoundationDB와 함께 통합해 사용 사례 확장

7. CockroachDB: 글로벌 데이터베이스

  • CockroachDB는 글로벌 분산 데이터베이스
    • PostgreSQL 와이어 프로토콜과 호환되며, 수평 확장과 강한 일관성을 지원
    • Google Spanner에서 영감을 받은 설계로, 다중 지역에 걸친 데이터베이스 확장을 가능케 함
  • CockroachDB의 주요 기술적 특징
    • 시간 동기화 기술:
      • Google Spanner는 원자 시계와 GPS 시계를 사용하지만, CockroachDB는 일반 하드웨어에서도 동작하도록 설계
      • NTP 기반 동기화 지연 보정, 노드 간 클록 드리프트 비교 및 최대 오프셋 초과 시 멤버 종료
    • 다중 지역 구성:
      • 테이블 로컬리티(Table Localities) 기능을 통해 읽기/쓰기 트레이드오프에 따른 최적화 가능
      • 데이터가 사용자 지리적 위치에 맞게 분산되어 성능과 지연 시간을 개선
  • CockroachDB 활용 학습 제안
    • MovR 예제 재구현:
      • 원하는 언어와 프레임워크를 사용해 MovR(분산 애플리케이션 예제)을 구현
    • CockroachDB의 다중 지역 및 스케일링 전략을 활용하여 글로벌 애플리케이션 설계 실험
  • CockroachDB 선택 이유
    • DynamoDB와 같은 다른 분산 데이터베이스와 달리 로컬 환경에서 무료로 실행 가능
    • 강한 일관성과 글로벌 분산 지원이라는 차별화된 특성 제공

Wrap Up

  • 소개된 데이터베이스는 각기 다른 문제와 요구 사항을 해결하기 위해 설계됨
  • 2025년엔 이 데이터베이스들을 학습하며 더 흥미롭고 창의적인 문제 해결 방법을 탐구해보세요!

Duckdb 분석 성능면에서 생각보다 탁월하여 깜짝 놀랐습니다

혹시 개발자 러닝커브가 걱정되는 환경이라면 SQLite 추천합니다. 파일기반이라 쉬워요.

SQLITE 쓰겠다고 이야기하면 욕먹기 좋은데, SQLITE 썼다고 이야기하기 전에는 아무도 모르기도 하죠... SQLITE 생각보다 좋습니다.

원격접근 요구사항이 없는게 확실시되면 정말 만족스러운 솔루션입니다. DB 관리포인트 없어지고 데이터 편집,백업/복구도 간편해서 좋습니다

몇달째 sqlite로. 일자별. 200만건, 5GB 수준의 데이터를 처리하는 작업을 수행하고 있습니다.

처리속도는 만족하는데.. 이 녀석을 가공후 다시 엑셀로 만들어서 이해당사자들에게 제공하는 시간이 너무 오래걸리고 있습니다.

OpenPyXl을 사용하는 방식에 연구를 좀 해야할거 같습니다.

무슨 매직이 있는지 몰라도 duckDB + sqlite 조합을 쓴다고 하네요.

의외로 MongoDB 가 언급되지 않았군요.

수십년(??)째 MySQL만 사용 중인데,
PostgreSQL은 어떠한지 현업에서 프러덕션으로 PostgreSQL 사용하시는 분들의 많은 댓글 기대합니다.

회사일때문에 Oracle, Sqlserver만 쓰다가 MySQL을 사용하려고 해보니 정말 "왜 이게 안되지?" 하는게 너무 많았습니다. 저도 정확하게는 기억이 안나네요.
결국은 Postgres로 넘어왔습니다.

Postgres 쓰다가 MySQL 쓰는곳으로 와서, 느낌 상 왜 이게 안돼? 왜 이게 성능이 안나오지? 하는 것들이 꽤 있습니다.
정확하게 뭐였는지 기억은 잘 안납니다 (사소할수도 아닐수도)

"코끼리는 물개보다 우수합니다"
이는 대부분의 상황에서 사실입니다

2001년에 버그 가득한 mysql(당시 v3.x)에서 pgsql로 넘어왔습니다.
우월하다 생각하는 부분이 많지만.. 현실에서는 Partial Index의 존재가 가장 강력한 기능이라고 생각합니다.