2025년 8월 29일·7분
업계 유행이 아니라 액세스 패턴으로 데이터베이스 선택하기
읽기/쓰기 경로, 지연시간, 일관성, 성장 요구를 기준으로 데이터베이스를 선택하는 실용 가이드 — 유행 때문에 생기는 불필요한 기술 부채를 피하세요.
읽기/쓰기 경로, 지연시간, 일관성, 성장 요구를 기준으로 데이터베이스를 선택하는 실용 가이드 — 유행 때문에 생기는 불필요한 기술 부채를 피하세요.
“인기라서” 데이터베이스를 고르는 것은, 스쿠터가 필요한지 픽업이 필요한지 버스가 필요한지 확인하지 않고 사람들이 많이 탄다는 이유로 차를 사는 것과 같습니다. 트렌드는 누군가의 제품, 팀 규모, 예산, 리스크 허용도를 반영합니다. 데이터베이스는 당신의 워크로드에 맞아야 합니다: 애플리케이션이 실제로 매일 무엇을 하는지에 따라 달라집니다.
워크로드는 운영 환경에서 시스템이 실제로 보이는 행동입니다:
이 행동들이 바로 당신의 액세스 패턴입니다—앱이 데이터를 반복적으로 건드리는 방식입니다. 액세스 패턴을 명확히 설명할 수 있다면, 데이터베이스 선택은 훨씬 덜 불확실해집니다.
하나의 솔루션이 모든 것을 해결하는 경우는 드뭅니다. 많은 성공적인 시스템은 하이브리드 접근을 사용합니다: 트랜잭션에 최적화된 DB, 분석용 DB, 전용 검색 엔진 또는 캐시를 동시에 사용합니다. 이는 불필요한 복잡성이 아니라, 서로 다른 액세스 패턴이 서로 다른 저장·조회 엔진에서 이득을 보기 때문입니다.
“SQL 대 NoSQL”을 비교하거나 유행을 쫓기 전에, 상위 5–10개의 읽기와 쓰기를 적어보세요. 거기서 시작하면 나머지는 세부사항입니다.
액세스 패턴은 애플리케이션이 일상적으로 데이터를 어떻게 건드리는지를 실용적으로 설명한 것입니다: 무엇을 읽고 쓰는지, 얼마나 자주, 얼마나 빠르게, 어떤 형태로 쿼리하는지. 이는 데이터가 무엇인지(“주문”이나 “사용자”)보다는 무엇을 하는지(“ID로 주문을 분당 1만 번 조회”)에 관한 문제입니다.
대부분의 읽기 트래픽은 몇 가지 형태로 나뉩니다:
소셜 피드는 혼합된 읽기 형태의 좋은 예입니다: 프로필은 포인트 조회, 최신 게시물은 범위 읽기, 카운트는 집계가 필요합니다.
쓰기 패턴도 중요합니다:
로그는 보통 “쓰기 집중적이고 append-only”(많은 삽입, 적은 업데이트)입니다. 주문은 보통 “생성 후 업데이트”(생성 후 상태 변경) 패턴입니다.
많은 제품은 한 번에 모든 것을 원합니다: 앱을 위한 빠른 포인트 조회, 고객지원용 복잡한 쿼리, 분석용 대규모 스캔. 하나의 데이터베이스로 일부 혼합을 잘 처리할 수 있지만, 특정 조합은 서로 충돌합니다—예를 들어 무거운 분석 스캔이 체크아웃이나 피드 같은 지연 민감한 작은 읽기를 느리게 만들 수 있습니다.
액세스 패턴을 명확히 이름 붙일 수 있으면, 데이터베이스를 유행 대신 실제 행동으로 평가할 수 있습니다.
데이터베이스 종류를 비교하기 전에, 실제로 제공하는 워크로드를 명확히 하세요. 대부분의 제품은 “하나의 워크로드”가 아니라 몇 가지 다른 워크로드가 공존합니다(때로는 경쟁적). 이 분류를 초기에 정확히 하면 데이터베이스를 본래 목적과 다르게 억지로 맞추는 일을 막을 수 있습니다.
OLTP는 대부분의 앱에서 일상적 심장박동과 같습니다: 많은 소규모 읽기/쓰기, 동시 사용자 다수, 빠르게 끝나야 하는 요청.
예: “장바구니 업데이트”, “주문 생성”, “주소 변경”, “재고 확인.” 이 작업들은 짧고 표적적이며 정확성에 민감합니다. 결제가 완료되면 사라지면 안 되고, 좌석 예약은 두 명이 동시에 못 하도록 해야 합니다.
OLTP는 보통 높은 동시성을 잘 처리하고 트랜잭션과 데이터 무결성에 대한 명확한 보장을 제공하는 시스템을 요구합니다.
분석은 작업의 형태를 뒤집습니다: 쿼리는 적지만 각각이 훨씬 많은 데이터를 건드립니다.
예: “지난 분기 지역별 수익”, “채널별 전환”, “카테고리별 상위 상품”, “DAU 추이”. 이 쿼리들은 흔히 많은 행을 스캔하고 그룹화·집계·정렬합니다. 지연 허용범위는 더 넓을 수 있지만(초 단위 허용) 무거운 스캔의 비용은 중요합니다—특히 대시보드가 하루 종일 실행될 때.
OLAP 스타일 스캔을 체크아웃을 담당하는 동일 시스템에서 돌리면 보통 둘 중 하나가 고통받습니다.
시계열과 로그는 보통 계속해서 이벤트가 도착하는 append-heavy 패턴입니다. 시간 범위로 쿼리하는 경우가 많습니다.
예: 메트릭, 클릭스트림, 디바이스 텔레메트리, 감사 로그. 필요한 기능은 보관 정책(오래된 데이터 삭제/만료), 롤업(원시 이벤트는 7일, 집계는 12개월 등), 스파이크 시 빠른 쓰기 처리입니다.
이 워크로드는 복잡한 조인보다 많은 타임스탬프 레코드를 효율적으로 수집하고 시간이 지나도 저장소 예측 가능하게 유지하는 것이 핵심입니다.
검색은 단순히 “행 찾기”가 아닙니다. 텍스트 매칭, 관련도 랭킹, 부분 일치, 사용자가 이해하기 쉬운 필터링이 필요합니다.
예: 키워드로 상품 검색, 문구로 티켓 찾기, 브랜드/가격대/색상 같은 페싯 필터, “최적 일치”로 정렬 등. 일반 목적 DB도 이를 어느 정도 흉내 낼 수 있지만 전문 검색 엔진만큼 잘하지는 못합니다.
검색이 핵심 기능이라면, 시작부터 별도의 워크로드로 다루세요. “나중에 추가”할 문제가 아닙니다.
성능은 단일 숫자가 아닙니다. 두 개의 데이터베이스가 둘 다 “빠르다”고 해도 사용자와 운영자가 느끼는 감각은 완전히 다를 수 있습니다. 잘 선택하려면 사용자가 체감하는 것(지연시간)과 시스템이 지속해야 할 처리량(throughput)을 분리하고, 스파이크로 가정들을 스트레스 테스트하세요.
**지연(latency)**은 단일 요청이 걸리는 시간—"버튼 누르고 결과 받기"입니다. 사용자가 직접 느낍니다.
**처리량(throughput)**은 초당 처리할 수 있는 요청 수—시스템이 총 얼마만큼의 트래픽을 감당할 수 있는지입니다.
어떤 DB는 배치로 작업을 효율화해 높은 처리량을 내지만 개별 요청 지연은 눈에 띄게 길 수 있습니다. 반대로 빠른 포인트 읽기를 최적화한 DB는 많은 쓰기가 동시에 몰리면 고생할 수 있습니다.
평균 지연은 고통을 숨깁니다. 99개의 요청이 50ms에 끝나고 1개가 2초가 걸리면 평균은 괜찮아 보이지만, 그 1%가 “앱이 느리다”는 인상을 남깁니다.
그래서 P99 지연이 중요합니다: 상위 1% 요청이 걸리는 시간입니다. 사용자 인터랙티브 기능(결제, 로그인, 검색)에서는 P99가 데이터베이스 설계의 체감 신뢰도를 결정하는 지표인 경우가 많습니다.
대부분의 시스템은 평균 트래픽에서 망가지지 않습니다; 피크에서 망합니다: 마케팅 이메일, 뉴스 브레이크, 급격한 트래픽, 월말 리포트 등.
스파이크는 데이터베이스 대화를 바꿉니다:
캐시는 읽기 중심 워크로드를 작아 보이게 만들 수 있지만, 캐시 미스나 정리 시 데이터베이스는 주로 쓰기와 가끔 발생하는 비용 높은 읽기를 처리하게 됩니다. 이는 모든 읽기가 DB에 가는 경우와 다른 선택을 필요로 합니다. “콜드 캐시” 이벤트와 미스의 꼬리 지연을 계획하세요, 단지 정상 경로만 고려하지 마십시오.
데이터베이스 선택은 속도뿐 아니라 무엇이 잘못되어도 되는지, 다운타임을 얼마나 견딜 수 있는지, 사용자 위치가 어디인지에 대한 문제입니다.
먼저 매번 정확해야 하는 데이터를 명명하세요. 결제, 계좌 잔액, 재고 수량이 대표적입니다. 고객이 이중 청구되거나 재고를 초과 판매하면 늦은 비용은 환불, 지원 티켓, 신뢰 손실입니다.
이런 부분에는 보통 강력한 보장이 필요합니다: 쓰기는 완료 확인 후에만 완료로 간주되고, 읽기는 반쯤 완료된 상태를 보지 않아야 합니다. 강한 정합성은 유연성을 줄이고 다중 지역 쓰기를 느리게 만들 수 있습니다.
데이터베이스가 5분 동안 없어지면 어떤 일이 벌어지는지 결정하세요.
“주문 중단 = 수익 중단”이라면 높은 가용성(자동 페일오버, 좋은 백업, 유지보수 중에도 앱을 내리지 않는 계획)이 필요합니다. 내부 대시보드 지연이라면 더 단순한 구성이 허용될 수 있습니다.
높은 가용성은 보통 비용과 운영 복잡도를 높입니다(레플리카 더 늘리기, 모니터링 강화, 신중한 업그레이드).
대부분 사용자가 한 리전에 모여 있다면 데이터 단일 보관이 더 싸고 빠릅니다. 사용자나 규제 요구로 다중 리전이 필요하면 복제를 고려해야 합니다.
다중 리전은 사용자 경험과 복원력을 높이지만 어려운 선택을 강요합니다: 약간 오래된 읽기를 허용할 것인지, 완전 동기화를 위해 쓰기를 느리게 할 것인지. 정답은 워크로드의 허용 범위에 달려 있습니다.
대부분의 “데이터베이스 논쟁”은 사실 쿼리 형태에 관한 논쟁입니다. 앱이 어떤 질문을 던져야 하는지(조인, 집계, 필터, 시간 윈도우)를 알면 선택지를 빠르게 좁힐 수 있습니다.
관계형 모델은 여러 엔티티(customer → order → item) 간의 유연한 필터링과 조인이 필요하고 요구사항이 진화할 때 빛을 발합니다. “X를 구매하고 Y를 반품한 고객 전부 보여줘” 같은 애드혹 리포팅이 필요하면 SQL과 조인이 시간이 지나도 간단한 경우가 많습니다.
반대로 쿼리가 예측 가능하고 주로 기본 키로 읽는다면 문서형이나 키-값 모델이 잘 작동합니다(읽는 형태대로 데이터를 함께 저장). 대가는 조인을 피하기 위해 데이터를 중복하게 되고, 쓰기와 업데이트가 더 복잡해진다는 점입니다.
인덱스는 데이터베이스에 “이게 내 액세스 패턴이다”라고 알려주는 방법입니다. 목업에서는 괜찮아 보이는 쿼리도 필터나 정렬에 인덱스가 없으면 느릴 수 있습니다.
규칙: 자주 사용하는 필터·정렬·조인 키마다 인덱스 계획을 세우세요. 단 인덱스는 공짜가 아니며 저장공간을 쓰고 쓰기를 느리게 합니다.
“빠른 쓰기”라는 주장에는 보통 쓰기 증폭이 숨겨져 있습니다—보조 인덱스, 압축/병합, 복제, 중복 데이터 업데이트 등으로 인해 추가 작업이 발생합니다. 읽기 성능을 위해 인덱스나 중복을 늘리면 고집적 쓰기 워크로드에서 병목이 될 수 있습니다.
스키마리스가 구조가 없다는 뜻은 아닙니다. 유연한 스키마는 초기 반복을 빠르게 하지만 규약이 없으면 필드 불일치, 디버깅 어려움, 비용 큰 마이그레이션으로 이어집니다. 많은 팀, 많은 기능, 긴 보관 기간이 예상된다면 더 엄격한 스키마와 제약이 총비용을 줄이는 경우가 많습니다—초기에 느려 보이더라도요.
인기 때문에 고른 데이터베이스는 운영·안전·월별 청구서 같은 소소하지만 중요한 소유의 문제에서 종종 실패합니다. 기능적으로 동일한 요구를 만족해도 운영 노력과 총비용은 천차만별일 수 있습니다.
누가 새벽 2시에 이 시스템을 운영할지 일찍 물어보세요. 백업, 시점 복구, 업그레이드, 패치, 페일오버 연습, 모니터링은 “나중의 일”이 아니라 위험과 인력 구성을 결정합니다.
관리형 서비스는 수고를 줄이지만 완전히 없애지는 않습니다. 어떤 시스템은 정기적 압축·튜닝·전문지식이 필요합니다. 팀이 작다면 운영하기 쉬운 데이터베이스가 종종 이론적으로 완벽한 후보보다 나을 수 있습니다.
데이터베이스 비용은 보통 다음에서 옵니다:
쓰기와 보조 인덱스가 많은 액세스 패턴은 데이터셋이 작아도 I/O와 스토리지를 곱절로 늘릴 수 있습니다.
독점 쿼리 언어, 고유한 일관성 기능, 서버리스 ‘마법’은 빠른 개발을 가능하게 하지만 나중에 이동을 어렵게 할 수 있습니다. 데이터를 내보낼 수 있는지, 로컬에서 테스트할 수 있는지, 공급자 변경 시 앱을 다시 써야 하는지를 고려하세요.
최소한 전송/저장 시 암호화, 키 관리 옵션, 감사, 접근 제어, 보관 정책을 확인하세요. 준수 요구는 유행성 여부와 상관없이 ‘사용 가능’과 ‘허용 가능’의 차이를 결정합니다.
액세스 패턴(무엇을 읽고, 무엇을 쓰며, 얼마나 자주, 스파이크는 어떤지)을 설명하면 보통 올바른 데이터베이스 계열이 명확해집니다. 목표는 가장 인기 있는 도구를 고르는 것이 아니라, 워크로드에서 정확성을 유지하는 가장 단순한 시스템을 고르는 것입니다.
강한 일관성, 명확한 관계, 신뢰할 수 있는 트랜잭션이 필요하면 관계형 DB를 선택하세요—주문, 결제, 재고, 권한, 스케줄링 등. 엔티티 간의 조인(“30일 내 미결제 청구서가 있는 고객”)이나 제약(유니크 이메일, 외래키)을 자주 사용하면 SQL이 앱 복잡도를 줄여줍니다.
휴리스틱: 팀이 조인·제약·트랜잭션을 코드로 재구현하려 한다면 관계형 DB가 필요할 가능성이 높습니다.
문서 DB는 주로 전체 오브젝트를 읽고 쓰며 구조가 가변적인 경우에 적합합니다(사용자 프로필, 콘텐츠 페이지, 선택적 필드가 많은 상품 카탈로그, 설정 등). 일반적 쿼리가 “user_id로 프로필 가져오기”라면, 문서가 함께 묶여 있어서 효율적입니다.
다만 쿼리가 고도로 관계형이 되거나 다중 엔티티 트랜잭션 보장이 필요하면 주의하세요.
캐시, 세션, 레이트 리미트, 기능 플래그 같은 키-값 시스템이 강점을 보입니다. 접근 패턴이 “키로 get/set”이고 지연이 중요할 때 보통 보완 역할을 합니다. 내구성이 필요한 핵심 비즈니스 데이터라면 퇴거(eviction), 재시작, 복제 지연 시 어떻게 되는지 질문하세요.
대규모 집계, 코호트 분석, 매출 롤업 같은 분석에는 컬럼형/웨어하우스가 유리합니다. 많은 행을 스캔하고 집계하는 데 최적화되어 있기 때문입니다.
실용적 분할: OLTP 쓰기는 기본 DB에 두고, 리포팅용으로 웨어하우스로 데이터를 공급하세요. 이렇게 하면 고객 인터랙션 쿼리에 BI가 영향을 주지 않습니다.
성공적인 제품은 보통 ‘하나의 DB를 고른다’기보다, 주요 액세스 패턴마다 가장 단순한 저장소를 매핑합니다. 두세 개의 DB를 나란히 쓰는 경우가 흔합니다.
온라인 상점은 종종 세 가지 다른 워크로드가 있습니다:
제품은 통합되어 보이지만 저장소는 액세스 패턴별로 특화되어 있습니다.
B2B SaaS는 핵심 엔티티(프로젝트, 인보이스, 티켓)를 트랜잭션 DB에 두되, 다음이 필요할 수 있습니다:
IoT 플랫폼은 텔레메트리를 버스트로 수집하고 시간 창 대시보드로 읽어야 합니다.
일반적 분할: 최근 데이터를 위한 빠른 인제스천 저장소, 장기 보관을 위한 저렴한 스토리지, 집계를 위한 분석 엔진.
핵심은 액세스 패턴이 갈라질 때 구성 요소마다 다른 DB를 쓰는 것이 종종 옳다는 점입니다.
데이터베이스 불일치는 보통 작은 ‘수정’ 작업들이 쌓이면서 드러납니다. 팀이 DB와 싸우는 데 더 많은 시간을 쓰면 주의하세요—대부분은 액세스 패턴의 문제이지 튜닝 문제입니다.
자주 반복되는 경고 신호:
정상적인 운영을 유지하려고 영웅적인 노력이 필요하면, 워크로드와 데이터베이스 계열이 맞지 않을 가능성이 큽니다.
인기 때문에 선택하면 장기 비용이 발생합니다:
규모나 요구가 변할 때 청구서는 도래하고 현실적인 해결책은 고통스러운 리플랫폼이 됩니다.
완벽한 가시성이 없어도 몇 가지 신호는 필요합니다:
상위 액세스 패턴(읽기/쓰기, 핵심 쿼리, 피크 속도), 데이터량 가정, ‘비타협’ 요구사항(정합성, 가용성, 리전 제약)을 적어두세요. 대시보드 링크와 최악의 쿼리 예시도 추가하세요. 이 짧은 기록은 미래 결정을 빠르게 하고 데이터베이스가 현실에 맞지 않을 때 명확히 알려줍니다.
데이터베이스 선택은 인기 경쟁이 아니라 요구사항 수집입니다. 이 체크리스트로 “확장성이 필요하다”는 모호한 요구를 비교 가능한 입력으로 바꾸세요.
먼저 평이한 언어로 답하고 가능하면 숫자를 덧붙이세요:
왼쪽에 기준을, 위에 후보 DB를 두고 한 페이지 표를 만드세요. 각 기준을 필수 또는 있으면 좋은으로 표시하고 데이터베이스마다 점수(예: 0–2)를 매기세요.
최소 포함 항목: 쿼리 적합성, 확장 방식, 일관성 요구, 운영 노력, 생태계/툴링, 비용 예측성.
대표 데이터와 실제 쿼리로 테스트하세요, 장난감 예제가 아니라 실제 상위 쿼리를 재현하고 쓰기 패턴(스파이크 포함)을 시뮬레이션하세요.
제품 아이디어를 빠르게 반복하려면 Koder.ai와 같은 vibe-coding 환경을 이용해 React 프론트엔드와 Go + PostgreSQL 백엔드를 빠르게 띄우고, 실제 엔드포인트 몇 개를 모델링한 뒤 “상위 5개 쿼리”의 동작을 측정해 장기 아키텍처를 결정하기 전 검증할 수 있습니다. 소스 코드 내보내기와 스키마/마이그레이션 제어 기능도 도구에 종속되는 일을 줄여줍니다.
사전합의로 “통과”가 무엇인지 적어두세요: 지연 목표, 허용 오류율, 필요한 운영 절차(백업, 스키마 변경), 예상 월별 비용. 후보가 PoC에서 필수 요건을 못 맞추면 조기에 제외하세요.
미래 대비는 초기부터 “가장 확장 가능한” DB를 고르는 것이 아니라, 액세스 패턴 변화에 민첩하게 대응할 수 있는 의도적인 선택을 하는 것입니다.
워크로드가 주로 트랜잭션성 읽기/쓰기이고 쿼리가 단순하다면 관계형 DB가 신뢰할 수 있는 제품을 빠르게 내는 최단 경로인 경우가 많습니다. 목표는 신뢰성 있게 배포하는 것: 예측 가능한 성능, 명확한 정합성 보장, 팀이 이미 아는 도구와 절차.
여기서의 “미래 대비”는 검증되지 않은 특화 저장소를 초기부터 채택해 돌이킬 수 없는 결정을 하는 것을 피하는 것입니다.
명시적 데이터 접근 레이어(또는 서비스 경계)를 만들어 앱의 나머지 부분이 DB 특정 특성에 의존하지 않게 하세요. 쿼리 로직을 중앙화하고 계약(입력/출력)을 정의하며 스키마 변경을 정상 개발의 일부로 취급하세요.
나중 마이그레이션에 도움되는 실습:
많은 제품은 결국 두 경로가 필요합니다: 일상 트랜잭션을 위한 OLTP와 리포팅·실험을 위한 분석. 분석 쿼리가 프로덕션 지연을 해치기 시작하거나 보관/파티셔닝 요구가 달라질 때 분리하세요.
두 시스템을 정렬하려면 이벤트/데이터 정의를 표준화하고 파이프라인을 자동화하며(예: 일별 매출 합계) 시스템 간 합계를 맞춰 ‘진실’이 분산되지 않게 하세요.
원한다면 다음 단계로 팀이 재사용할 수 있는 가벼운 마이그레이션 플랜 템플릿을 만들어 보세요: /blog/database-migration-checklist.
액세스 패턴은 실제 운영에서 앱이 데이터를 다루는 반복 가능한 방식입니다: 무엇을 읽고 쓸지, 얼마나 자주, 얼마나 빠르게, 어떤 쿼리 형태인지(포인트 조회, 범위 스캔, 조인, 집계, 시간 윈도우 등). “사용자와 주문이 있다”는 수준보다 더 실무적이며, 인덱스·스키마·데이터베이스 적합성으로 곧바로 연결됩니다.
“인기”는 다른 팀의 요구사항(제품, 인원, 예산, 리스크 수용도)을 반영할 뿐입니다. 동일한 데이터베이스가 어떤 워크로드에는 훌륭하지만 다른 워크로드(예: 대규모 분석 스캔)에는 고통이 될 수 있습니다. 우선 상위 5–10개의 읽기/쓰기 패턴을 적고, 그 행동을 기준으로 데이터베이스를 평가하세요. 브랜드 흐름에 휩쓸리지 마십시오.
먼저 적으세요:
이 문서가 옵션 비교용 요구사항이 됩니다.
OLTP는 많은 소규모 동시 읽기/쓰기, 높은 동시성, 정확성이 중요한 작업(결제, 재고 등)입니다. 트랜잭션과 제약을 잘 처리하는 시스템이 적합합니다.
OLAP/분석은 적은 쿼리지만 많은 데이터를 건드리는 작업(스캔, 그룹바이, 대시보드)으로 초당 응답 수 초 단위가 허용될 수 있으나 무거운 스캔이 비용을 유발합니다.
둘을 한 시스템에 섞으면 분석 스캔이 사용자 지연을 악화시키는 경우가 많습니다.
평균이 아니라 p95/p99 지연시간을 보세요. 요청의 상위 1%가 수초가 걸리면 평균이 좋아 보여도 사용자는 앱이 느리다고 느낍니다.
실용 팁: 로그인·결제·검색 같은 중요 엔드포인트는 p95/p99를 별도로 모니터링하고, 지연 스파이크를 데이터베이스 지표(락, 복제 지연, I/O 포화)와 연관지어 분석하세요.
경우에 따라 서로 다른 요구가 충돌합니다:
전문화된 저장소를 사용하는 것이 하나의 DB에 모든 것을 억지로 맞추는 것보다 전체적으로 더 단순한 경우가 많습니다.
캐시는 읽기 부하를 숨길 수 있지만 캐시 미스나 캐시 삭제 시 본체 DB가 받는 부하가 진짜 병목이 됩니다.
캐시는 문제를 일시적으로 가릴 수 있지만, 미스가 폭주하면 급격한 장애로 이어질 수 있습니다.
강한 정합성은 트랜잭션과 업데이트의 완전성이 반드시 보장되어야 하는 경우입니다(결제, 잔액, 예약 등). 이런 데이터는 “절대 틀리면 안 되는” 항목으로 분류하고 강한 보장을 제공하는 저장소를 선택하세요.
대가로는 다중 지역 쓰기가 느려질 수 있고, 확장 전략이 까다로워질 수 있습니다. 어떤 데이터가 허용 가능한 지연 또는 불일치를 견딜 수 있는지 명확히 하세요.
인덱스는 워크로드와 데이터베이스 사이의 성능 계약입니다. 자주 사용하는 필터·정렬·조인 키·시간 범위 쿼리에 대해 인덱스를 계획하세요.
단, 인덱스는 저장공간을 쓰고 쓰기를 무겁게 만듭니다(쓰기 증폭). 실제로 자주 사용하는 것에만 인덱스를 주는 것이 목적입니다.
좋은 PoC는 작은 프로덕션 리허설입니다:
PoC에서 ‘필수 요건’을 못 맞추면 조기에 후보에서 제외하세요.