태그: #database

한국어English日本語中文

← 전체 글

• 지금 주목받는 오픈소스 (3) 인프라와 데이터베이스

  데이터베이스와 인프라 영역은 라이선스 변경과 포크가 판을 다시 짠 분야입니다. 분석 엔진, 임베디드 데이터베이스, 포스트그레스 확장, 쿠버네티스 오퍼레이터, IaC까지 실제로 자리를 잡은 오픈소스 11개를 스타 순위가 아니라 해결하는 문제별로 묶어 소개합니다. 무엇을 대체하는지, 어느 정도 성숙했는지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는

  2026-08-12 · 9 분 읽기 #open-source#database#infrastructure#postgresql#kubernetes

• 데이터 저장소와 큐의 세대교체 — 라이선스, 포크, 그리고 Attic으로 간 프로젝트들

  데이터 계층에서 자리를 내주었거나 배포 조건이 바뀐 프로젝트 10개를 공식 발표문과 Apache Attic 기록만 근거로 정리합니다. Redis와 Elasticsearch, MongoDB의 라이선스 변경과 그로 인해 생긴 Valkey, OpenSearch 포크를 사실만으로 다루고, Kafka에서 ZooKeeper가 빠진 과정, Apache Attic으로 이관된 Sqoop과 Oozie, Gir

  2026-08-12 · 18 분 읽기 #open-source#database#kafka#redis#elasticsearch

• 국내 개발 블로그 명글 큐레이션 2 — 장애 회고와 트러블슈팅, 직접 열어 확인한 12편

  한국 개발자가 가장 잘 쓰는 장르는 장애 회고입니다. p6spy가 DB 라우팅을 무력화한 사건, HTTP 타임아웃이 DNS 조회를 덮지 못한 이유, TCP 하프 클로즈가 중복 예외로 위장된 사례, MetalLB 설정 하나가 만든 클러스터 지연 스파이크, 힙 덤프로 OOM을 추적한 기록, JIT 워밍업으로 배포 직후 CPU 스파이크를 잡은 과정, 외래키가 부른 데드락, HikariCP 커넥션

  2026-08-12 · 22 분 읽기 #curation#큐레이션#troubleshooting#postmortem#incident

• 300배는 PostgreSQL을 튜닝해서 나온 숫자가 아니다 — 화산 모델과 벡터화 실행

  pgrust 0.2 릴리스와 함께 공개된 300배라는 숫자를 정확히 해부합니다. 이 수치는 PostgreSQL 설정을 바꿔서 나온 것이 아니라 Rust로 새로 구현한 데이터베이스를 ClickBench에서 측정한 결과이며, 저자 본인이 별도로 제시한 SUM 쿼리 실험은 화산 모델 1.3초에서 SIMD 135밀리초까지 9.6배를 보여 줍니다. 배치, 연산자 융합, SIMD가 각각 무엇을 제거하는

  2026-08-09 · 15 분 읽기 #postgresql#database#performance#query-engine#simd

• SQL 인젝션과 파라미터 바인딩 — ORM을 써도 뚫리는 지점들

  SQL 인젝션 대응책으로 가장 먼저 검색되는 것은 이스케이프 함수지만, 정답은 파라미터 바인딩입니다. 이스케이프는 값을 문자열 리터럴 안에서 안전하게 만들려는 시도이고, 바인딩은 값이 SQL 텍스트에 아예 들어가지 않게 만드는 구조적 분리이기 때문입니다. 이 글은 프리페어드 스테이트먼트가 서버에서 실제로 어떻게 파싱되고 실행되는지 로그로 확인하고, ORM을 쓰는데도 뚫리는 세 가지 지점과 O

  2026-07-26 · 26 분 읽기 #security#sql#database#orm#python

• EXPLAIN ANALYZE 읽는 법 — 실행 계획에서 진짜 병목을 찾는 순서

  EXPLAIN ANALYZE 출력을 처음부터 끝까지 읽는 방법을 정리합니다. 노드를 어떤 순서로 읽어야 하는지, cost가 왜 시간 단위가 아닌지, 예상 행 수와 실제 행 수의 괴리가 무엇을 알려 주는지, loops가 곱해지는 함정은 어떻게 피하는지 실제 출력과 함께 설명합니다. Nested Loop, Hash Join, Merge Join이 각각 선택되는 조건과 BUFFERS로 캐시 적중을

  2026-07-26 · 21 분 읽기 #database#postgresql#explain#query-optimization#performance

• 트랜잭션 격리 수준과 실제 이상 현상 — 표준 정의가 구현과 다른 지점

  트랜잭션 격리 수준 네 가지와 dirty read, non-repeatable read, phantom read를 정리하되, 교과서의 표 하나로 끝내지 않습니다. PostgreSQL의 Read Committed가 왜 처음부터 dirty read를 만들 수 없는지, Repeatable Read가 왜 사실은 스냅샷 격리이고 직렬화 실패를 애플리케이션이 재시도해야 하는지, MySQL InnoDB의

  2026-07-26 · 22 분 읽기 #database#postgresql#transaction#isolation-level#mysql

• 커넥션 풀 크기, 크게 잡으면 손해인 이유 — 대기열을 어디에 세울 것인가

  커넥션 풀을 키웠더니 오히려 느려지는 현상의 원리를 정리합니다. PostgreSQL의 프로세스 모델에서 커넥션이 왜 비싼지, 디스크와 CPU 병렬성이 유한하므로 대기열을 데이터베이스 안이 아니라 풀에 세우는 편이 나은 이유, 자주 인용되는 코어 수 기반 공식의 근거와 한계를 다룹니다. 마이크로서비스에서 인스턴스 수와 풀 크기의 곱이 최대 커넥션을 넘기는 전형적 사고, PgBouncer 세 가

  2026-07-26 · 26 분 읽기 #database#postgresql#connection-pool#pgbouncer#performance

• 인덱스를 만들었는데 안 타는 이유 — 옵티마이저가 맞고 내가 틀린 경우들

  인덱스를 만들었는데 실행 계획에 Seq Scan이 그대로 남는 이유를 원인별로 정리합니다. 선택도가 낮아서 옵티마이저가 일부러 무시하는 경우, 컬럼에 함수나 연산이 걸려 sargable하지 않은 경우, 타입 불일치로 암묵적 캐스팅이 일어나는 경우, LIKE 선행 와일드카드, OR 조건, 복합 인덱스 선두 컬럼 규칙, 통계 노후화, NULL 처리까지 실제 SQL과 실행 계획으로 확인합니다. 부

  2026-07-26 · 21 분 읽기 #database#postgresql#index#query-optimization#mysql

• 데드락 진단과 예방 — 로그에서 두 쿼리를 특정하는 법

  deadlock detected 오류를 만났을 때 무엇을 봐야 하는지 순서대로 정리합니다. PostgreSQL의 데드락 리포트와 MySQL의 SHOW ENGINE INNODB STATUS 출력을 한 줄씩 해석해 어느 두 쿼리가 엮였는지 특정하는 방법, 실무에서 반복되는 세 가지 패턴인 갱신 순서 불일치와 인덱스 부재로 인한 락 범위 확대와 외래 키가 유발하는 부모 행 잠금을 다룹니다. dea

  2026-07-26 · 25 분 읽기 #database#postgresql#deadlock#locking#mysql

• Neo4j 캘버 시대 중간 점검 — 블록 포맷, Cypher 25, 그리고 GQL이 엔진에 착지하는 방식

  Neo4j는 2025년 초 캘린더 버저닝으로 전환한 뒤 약 17개월 동안 18개의 피처 릴리스를 냈고, 각 릴리스의 핫픽스 지원은 다음 릴리스가 나오는 순간 끝납니다. 이 글을 쓰는 2026년 7월 현재 캘버 라인에는 아직 LTS가 없어서, 안정 지원이 필요하면 5.26 LTS(핫픽스 2028년 6월까지)에 머물러야 하고 그 대가로 Cypher 25, VECTOR 타입, 새 GQL 문법을 포

  2026-07-17 · 26 분 읽기 #database#neo4j#graph-database#cypher#gql

• ClickHouse lazy materialization — LIMIT 10짜리 트릭이 FINAL과 JOIN까지 자란 과정

  ClickHouse의 lazy materialization은 정렬과 LIMIT이 끝나기 전에는 SELECT 컬럼을 읽지 않는 최적화로, 25.4(2025년 4월)에 LIMIT 10 이하에서만 켜지는 보수적인 기능으로 출발했습니다. 이후 행 단위 lookup을 조인 스타일 일괄 조회로 갈아엎은 25.12에서 게이트가 10,000까지 올라갔고, 2026년에는 26.2의 UNION ALL 전 브랜

  2026-07-17 · 24 분 읽기 #database#clickhouse#olap#query-optimization#performance

• Cassandra 6.0-alpha1과 Accord 트랜잭션 — 5년 만의 "범용 트랜잭션"은 지금 어디까지 왔나

  2021년 CEP-15로 제안된 Cassandra의 범용 트랜잭션 프로토콜 Accord가 2026년 3~4월, 마침내 6.0-alpha1이라는 실행 가능한 릴리스에 실려 나왔습니다. 리더 없는 합의로 멀티 파티션 strict-serializable 트랜잭션을 정상 조건에서 WAN 왕복 1회에 처리한다는 것이 프로토콜의 약속이고, BEGIN TRANSACTION 구문과 테이블별 transact

  2026-07-17 · 24 분 읽기 #database#cassandra#distributed-systems#transactions

• MySQL 9.7 다음 버전은 26.7 — 2026년 봄, MySQL과 MariaDB가 릴리스 모델을 정리한 방식

  2026년 4월 21일 MySQL 9.7.0이 GA로 나오면서 8.4 이후 거의 2년 만에 새 LTS 라인이 열렸고, 같은 달 MySQL 8.0은 Extended Support가 끝나 Sustaining Support로 내려갔습니다. 그리고 6월 16일 Oracle은 버전 번호를 YY.M 캘린더 버저닝으로 바꾼다고 발표해, 9.7 다음 혁신 릴리스는 9.8이 아니라 26.7이 됐습니다. Ma

  2026-07-16 · 34 분 읽기 #mysql#mariadb#database#versioning#devops

• InfluxDB 3 Core의 72시간 제한은 사실 432개 파일 제한이다 — Parquet 재작성이 남긴 청구서

  InfluxDB 3는 엔진 전체를 Rust로 다시 쓰고 저장 계층을 Apache Arrow와 Parquet 위에 올렸습니다. 흔히 "Core는 72시간까지만 조회된다"고 알려져 있지만 소스를 읽어 보면 그런 코드는 없습니다. 실제로 존재하는 것은 쿼리 하나가 스캔할 수 있는 Parquet 파일 개수 제한 432개이고, 72시간은 기본 gen1 블록 10분을 곱해서 나온 파생값이자 최선의 경우

  2026-07-16 · 34 분 읽기 #database#influxdb#time-series#parquet#storage-engine

• DuckDB에 클라이언트-서버 프로토콜이 생겼다 — Quack이 바꾸는 것과 바꾸지 않는 것

  2026년 5월 12일 DuckDB 팀이 Quack을 발표했습니다. HTTP 위에 얹은 클라이언트-서버 프로토콜로, DuckDB 인스턴스 두 개가 서로 클라이언트와 서버가 되어 같은 데이터베이스를 여러 프로세스에서 동시에 읽고 쓸 수 있게 합니다. 7년 동안 "인프로세스"를 정체성으로 내세운 프로젝트가 스스로 서버를 붙인 셈이라, 무엇이 바뀌었는지보다 무엇이 안 바뀌었는지가 더 중요합니다.

  2026-07-16 · 31 분 읽기 #database#duckdb#olap#analytics#data-engineering

• Postgres 19의 pg_plan_advice — 힌트를 거절해 온 프로젝트가 내놓은 타협안

  PostgreSQL 프로젝트는 오랫동안 옵티마이저 힌트를 거절해 왔습니다. 그런데 2026년 6월 4일 나온 PostgreSQL 19 Beta 1에 Robert Haas가 만든 pgplanadvice와 pgstashadvice가 contrib 모듈로 들어갔습니다. 이건 오라클식 힌트가 아닙니다 — 조언은 SQL 밖에 살고, 플래너를 대체하는 게 아니라 탐색 공간을 좁히기만 하며, 문서의 표현

  2026-07-16 · 26 분 읽기 #postgresql#query-planner#query-optimization#database#performance

• pgrust: Postgres를 Rust로 다시 쓰고 회귀 테스트 100%를 통과했다 — 그게 정말 뜻하는 것

  Malcolm Matis(malisper)가 Postgres를 Rust로 다시 쓴 pgrust를 공개했습니다. Postgres 18.3 호환을 목표로 4만6천 개가 넘는 회귀 테스트 쿼리를 통과하고, 실제 18.3 데이터 디렉터리에서 부팅됩니다. 이 글은 그 마일스톤이 왜 진짜로 인상적인지, 그리고 "회귀 테스트 100% 통과"가 무엇을 증명하고 무엇을 증명하지 않는지를 정직하게 뜯어봅니다.

  2026-07-11 · 12 분 읽기 #postgresql#rust#pgrust#database#regression-tests

• CloudNativePG로 쿠버네티스에 Postgres 띄우고 죽여보기 — 페일오버 23초 실측

  실제 8노드 쿠버네티스 클러스터에 CloudNativePG(CNPG) v1.30.0을 설치하고, 3인스턴스 Postgres 클러스터를 띄운 뒤, 정말로 프라이머리를 죽여봤습니다. 부트스트랩부터 복제 확인, 프라이머리 강제 삭제 후 페일오버(23.1초 만에 레플리카 승격, 데이터 무손실), 그리고 죽은 노드가 레플리카로 자가 복구되어 3/3으로 돌아오기까지 — 전 과정을 실측 로그와 함께 기록

  2026-07-11 · 9 분 읽기 #cloudnativepg#postgresql#kubernetes#operator#database

• MariaDB 아키텍처 — 스토리지 엔진부터 Galera까지

  MariaDB의 전체 서버 아키텍처를 연결 계층부터 파서, 옵티마이저, 실행기까지 따라가며 스토리지 엔진의 선택 기준과 복제, Galera 동기 멀티 마스터 클러스터, 파티셔닝을 정리합니다. MySQL과의 관계와 차이도 다이어그램과 비교표로 함께 살펴봅니다.

  2026-06-27 · 37 분 읽기 #mariadb#storage-engine#galera#replication#innodb