데이터베이스

"A database is an organized collection of structured information, or data, stored electronically in a computer system."

— 데이터베이스 기술의 학술적이고 아주 모범적인 교과서적 정의.

모든 웹 서비스 장애 보고서의 90%가 종착하는 마성의 수렴지이자, 인덱스 설계 하나 잘못했다가 회사를 파산 상태로 밀어 넣을 수 있는 무서운 화약고. ~~아 제발 이번 서비스 배포할 때 DB 스키마 마이그레이션하다가 테이블 락(Table Lock) 안 걸리게 해주세요...~~

1. 개요

데이터베이스는 컴퓨터 시스템에 전자적으로 저장되는 구조화된 정보 또는 데이터의 체계적인 집합이다. 현대 소프트웨어 공학에서 데이터를 저장, 수정, 조회, 삭제하는 모든 백엔드 로직의 궁극적 종착지이다.

메모리 상에 데이터를 보관하는 것은 휘발성의 위협이 크고, 파일 시스템에 날것으로 기록하는 것은 다중 요청 처리와 무결성 수호가 불가능하기 때문에 독자적인 트랜잭션과 고성능 검색 기능을 갖춘 DBMS(Database Management System)의 사용은 백엔드 개발의 마지노선이 되었다. 이로 인해 현대 백엔드 개발자들의 숙명적인 밤샘 작업과 긴급 장애 복구는 십중팔구 이 데이터베이스 서버를 둘러싸고 일어난다.(...)

2. 관계형(RDBMS)과 비관계형(NoSQL)의 영원한 라이벌 관계

2.1. 테이블의 제왕, 관계형 데이터베이스 (RDBMS)

오라클, MySQL, PostgreSQL로 대표되는 관계형 데이터베이스는 데이터를 행(Row)과 열(Column)을 가진 엄격한 표 구조로 관리한다. 데이터 간의 관계를 외래키(Foreign Key) 등으로 단단하게 엮어두며, SQL이라는 만능 분석용 무기를 제공한다.

가장 강력한 강점은 데이터 무결성을 절대적으로 수호하는 ACID 트랜잭션이다. 은행 계좌 이체처럼 단 0.0001초의 정합성 오류도 허용할 수 없는 엔터프라이즈 환경에서 절대 신뢰를 얻고 있다. 그러나 스키마 변경이 어렵고, 대용량 트래픽 확장을 위해 샤딩(Sharding)이나 분산 서버 구성을 하려 하면 밤샘 삽질이 예정되어 있다는 단점이 있다.¹

2.2. 자유의 수호자, 비관계형 데이터베이스 (NoSQL)

MongoDB나 Redis 같은 NoSQL 진영은 엄격한 테이블 구조와 스키마의 족쇄를 과감히 던져버렸다. JSON 문서 형태로 데이터를 마구 쑤셔 넣거나(Document DB), 빠른 키-값(Key-Value) 구조로 캐싱을 수행하며, 수평적 확장(Scale-out)이 매우 수월하다.

하지만 자유의 대가는 무겁다. 데이터 중복성이 심해지고, 데이터 간 정합성을 애플리케이션 수준에서 직접 보장해야 하는 눈물겨운 책임을 떠안아야 한다. 결국 현대 아키텍처는 무조건 둘 중 하나를 택하기보다는 대금 결제나 회원 정보는 RDBMS에, 로그나 실시간 데이터는 NoSQL에 분산 저장하는 영리한 타협(Polyglot Persistence)을 지향하고 있다.

3. 여담

가장 안전한 복구 대책, 백업: 데이터베이스에 대형 장애가 나거나 랜섬웨어에 걸려 데이터가 암호화되었을 때 유일하게 개발자의 목숨을 살려주는 구세주는 오직 '주기적인 오프라인 백업'뿐이다. 실제로 '백업이 없는 개발자는 두 종류가 있다. 백업을 안 하는 개발자와 백업의 소중함을 뼈저리게 느끼게 될 개발자'라는 격언이 실무에 버젓이 존재한다.
인덱스는 양날의 검: 데이터를 수천 배 빠르게 찾아주는 마법의 도구인 인덱스(Index)는 사실 공짜가 아니다. 인덱스를 추가할 때마다 데이터를 정렬하여 별도 메모리 공간에 가지고 있어야 하므로, INSERT나 UPDATE 속도가 눈에 띄게 저하된다. 만약 멋모르고 테이블의 모든 열에 인덱스를 발라버린다면, 데이터를 넣을 때마다 슬로우 쿼리 경고창이 도배되는 마술을 경험하게 된다.
오라클 라이선스의 포스: 오라클 데이터베이스의 성능은 세계 최고 수준이지만, 라이선스 비용 역시 지구상에서 가장 무자비하기로 유명하다. CPU 코어 개수 단위로 억 단위 수수료를 뜯어가기 때문에, 기술적 고도화보다 라이선스 감사를 어떻게 피할지 고민하는 전담 부서가 대기업마다 존재한다는 우스갯소리가 있다.

4. 관련 문서

실제로 RDBMS의 수평 확장은 고난도 아키텍처 기술이 요구되며, 분산 트랜잭션 정합성(2PC 등)을 유지하느라 벤더 솔루션 비용이 안드로메다로 날아가는 원흉이 된다. ↩