키 값 저장소편집자 확인

키 값 저장소의 가장 기본적인 구성 요소는 키와 값이다. 이 두 요소는 항상 쌍을 이루어 저장되고 관리된다.

키는 데이터를 고유하게 식별하는 문자열이다. 이는 데이터베이스의 기본 키와 유사한 역할을 하며, 값을 저장하거나 조회할 때 사용하는 주소 또는 식별자로 기능한다. 키는 일반적으로 간단한 문자열 형태를 가지며, 정렬 키를 지원하는 시스템에서는 복합 키 구조도 사용될 수 있다. 값은 키에 연관되어 저장되는 실제 데이터이다. 값의 형태는 시스템에 따라 크게 달라지는데, 단순한 문자열부터 정수, 리스트, 해시 맵, 심지어 이진 데이터 객체까지 다양한 데이터 타입을 지원한다. 값은 키를 통해 접근 가능하며, 그 내용은 불투명할 수 있다.

키와 값의 관계는 매우 단순하고 직접적이다. 하나의 키는 정확히 하나의 값에만 매핑된다. 이는 관계형 데이터베이스의 복잡한 스키마나 테이블 간의 관계와 대비되는 특징이다. 데이터 접근은 항상 키를 통해 이루어지며, 값에 대한 쿼리나 조건부 검색은 일반적으로 지원되지 않는다. 이 모델의 강점은 키를 알고 있다면 매우 빠르게(O(1)에 가까운 시간 복잡도로) 해당 값을 조회할 수 있다는 점이다.

키-값 저장소의 데이터 모델은 관계형 데이터베이스의 복잡한 스키마나 테이블 구조와 대비되어 매우 단순한 형태를 가집니다. 각 데이터 항목은 고유한 키와 그에 연관된 값의 쌍으로만 구성되며, 값은 일반적으로 문자열, 숫자, 이진 데이터 등 단일한 데이터 타입을 가집니다. 이 모델에서는 값 내부에 또 다른 구조를 정의하거나 값들 간의 명시적인 관계를 설정하지 않습니다. 이러한 단순성 덕분에 데이터 접근 패턴이 직관적이고 예측 가능해집니다.

이 모델의 핵심은 키를 통한 빠른 값의 조회에 있습니다. 시스템은 키를 해시 함수 등에 입력하여 데이터의 물리적 저장 위치를 직접 계산하거나 색인하여, 복잡한 쿼리나 조인 연산 없이도 매우 빠른 속도로 데이터에 접근할 수 있습니다. 값의 내용과 구조는 애플리케이션 계층에서 해석할 책임이 있으며, 저장소 자체는 값의 내부를 분석하지 않고 불투명한 BLOB으로 취급하는 경우가 많습니다.

단순한 데이터 모델의 제약은 다음과 같은 특성을 명확히 합니다.

이러한 단순성은 설계와 구현을 간소화하고, 높은 성능과 확장성을 가능하게 하는 동시에, 복잡한 쿼리나 트랜잭션 처리가 필요한 사용 사례에는 적합하지 않을 수 있는 트레이드오프를 만듭니다.

키 값 저장소는 CRUD 연산, 즉 데이터의 생성(Create), 읽기(Read), 갱신(Update), 삭제(Delete)를 기본적인 인터페이스로 제공한다. 이 연산들은 대부분 단일 키를 대상으로 수행되며, 복잡한 쿼리나 조인 연산은 지원하지 않는 것이 일반적이다.

주요 연산은 다음과 같다.

이러한 연산 외에, 일부 시스템은 여러 키를 한 번에 처리하는 배치 연산(예: MSET, MGET)이나 키의 존재 여부를 확인하는 EXISTS 연산, 모든 키를 나열하는 KEYS 또는 SCAN 연산 등을 추가로 제공하기도 한다. 그러나 범위 검색이나 조건부 쿼리 같은 복잡한 읽기 연산은 키 값 저장소의 단순한 모델에 부합하지 않으며, 이러한 요구사항은 보조 인덱스를 구축하거나 다른 유형의 데이터베이스를 사용해야 한다.

키 값 저장소의 가장 큰 장점은 단순한 데이터 모델에서 비롯된 높은 성능과 확장성이다. 키를 통한 데이터 접근은 매우 직관적이며, 복잡한 쿼리나 조인 연산이 필요 없기 때문에 읽기와 쓰기 속도가 매우 빠르다. 이는 대규모 트래픽을 처리해야 하는 웹 애플리케이션의 캐싱 계층이나 실시간 데이터 처리에 이상적이다. 또한, 데이터 구조가 단순하기 때문에 수평적 확장이 비교적 쉽게 이루어져, 데이터 양이 증가하거나 트래픽이 많아질 경우 여러 서버에 데이터를 분산 저장하는 샤딩을 통해 시스템 성능을 선형적으로 늘릴 수 있다.

또 다른 주요 장점은 유연한 스키마이다. 관계형 데이터베이스 관리 시스템과 달리 미리 정의된 스키마가 필요 없으며, 각 키에 연결된 값은 독립적으로 존재한다. 이는 애플리케이션의 요구사항이 빠르게 변하거나 다양한 형태의 데이터를 저장해야 할 때 큰 이점이 된다. 예를 들어, 사용자 프로필 정보에 새로운 필드를 추가해야 하는 경우, 기존 데이터 구조를 변경하지 않고도 새로운 키-값 쌍을 저장할 수 있다.

마지막으로, 많은 키-값 저장소가 제공하는 단순한 API는 개발 생산성을 높인다. 기본적인 CRUD 연산(생성, 읽기, 갱신, 삭제)에 초점을 맞춘 인터페이스는 학습 곡선이 낮고 구현이 간편하다. 이로 인해 개발자는 복잡한 데이터베이스 설계나 쿼리 최적화보다 핵심 비즈니스 로직에 더 집중할 수 있다.

키 값 저장소는 단순한 데이터 모델과 높은 성능을 제공하지만, 그 단순성으로 인해 몇 가지 명확한 제약 사항과 단점을 가진다.

가장 큰 단점은 복잡한 쿼리 기능의 부재이다. 키 값 저장소는 기본적으로 키를 통한 단일 항목 조회나 범위 스캔만을 지원하며, 값 내부의 필드를 기준으로 검색하거나 여러 테이블을 조인하는 등의 관계형 쿼리를 수행할 수 없다. 이는 애플리케이션 로직에서 추가적인 처리나 인덱스를 구축해야 할 필요성을 만들어낸다. 또한, 값이 불투명한 BLOB으로 처리되는 경우가 많아, 데이터베이스 수준에서 값의 구조나 무결성을 검증하기 어렵다.

운영 측면에서도 고려해야 할 점이 있다. 대부분의 키 값 저장소는 강력한 ACID 트랜잭션을 완전히 보장하지 않으며, 특히 분산 환경에서는 결과적 일관성과 같은 느슨한 일관성 모델을 채택한다[1]. 이는 데이터의 최신 상태를 항상 읽을 수 있음을 보장하지 않아, 애플리케이션 설계 시 주의를 요한다. 또한, 단순한 CRUD 연산에 최적화되어 있어, 집계 함수나 복잡한 분석 쿼리를 실행하는 데는 적합하지 않다.

따라서 키 값 저장소는 모든 유형의 데이터 저장 문제에 대한 만능 해결책이 아니라, 낮은 지연 시간과 높은 처리량이 요구되는 특정 사용 사례에 적합한 도구이다. 복잡한 비즈니스 로직이나 정교한 데이터 분석이 필요한 경우에는 관계형 데이터베이스나 다른 NoSQL 데이터베이스 유형을 함께 고려해야 한다.

인메모리 방식의 키 값 저장소는 모든 데이터를 주 메모리(RAM)에 저장하는 방식이다. 이 방식은 디스크 기반 접근 방식에 비해 매우 빠른 읽기 및 쓰기 성능을 제공하는 것이 가장 큰 특징이다. 데이터 접근 시 디스크 입출력(I/O)이 발생하지 않기 때문에 지연 시간이 극도로 낮고, 초당 처리 가능한 연산 수(TPS)가 매우 높다.

이 방식의 주요 구현체로는 Redis와 Memcached가 대표적이다. 이들은 데이터 구조를 단순한 문자열뿐만 아니라 리스트, 해시, 집합 등 다양한 형태로 저장할 수 있어, 단순 캐시 이상의 용도로 활용된다. 모든 작업이 메모리에서 이루어지기 때문에 데이터베이스나 애플리케이션 서버 앞단의 캐시 계층으로서 부하 분산과 성능 향상에 크게 기여한다.

인메모리 방식의 가장 큰 제약은 휘발성 메모리의 특성상 시스템 전원이 꺼지면 데이터가 사라진다는 점이다. 이러한 데이터 손실 위험을 완화하기 위해 주기적으로 데이터를 디스크에 저장하는 스냅샷 기능이나 변경 사항을 지속적으로 기록하는 AOF 같은 지속성 메커니즘을 함께 제공하는 시스템도 많다.

주요 사용 사례와 특징은 다음과 같이 정리할 수 있다.

이 방식은 높은 성능을 요구하지만, 데이터의 영구 보존이 최우선 순위가 아닌 상황에서 주로 선택된다. 메모리 용량이 물리적으로 제한되어 있어 대용량 데이터를 저장하기에는 비용이 많이 들 수 있다는 점도 고려해야 한다.

디스크 기반 방식의 키 값 저장소는 데이터를 주로 하드 디스크 드라이브나 솔리드 스테이트 드라이브와 같은 비휘발성 저장 장치에 지속적으로 보관하는 방식입니다. 이 방식은 인메모리 방식에 비해 일반적으로 접근 속도가 느리지만, 서버 재시작이나 장애 발생 시에도 데이터가 유지되는 내구성을 핵심 장점으로 제공합니다. 대용량 데이터를 상대적으로 저렴한 비용으로 저장해야 하는 경우에 적합합니다.

성능 최적화를 위해 디스크 기반 방식의 시스템들은 종종 로그 구조화 병합 트리나 B-트리와 같은 효율적인 디스크 자료 구조를 사용합니다. 또한, 쓰기 시 복사나 어펜드 전용 로그 방식을 채택하여 쓰기 성능을 향상시키기도 합니다. 데이터 접근 속도를 높이기 위해 메모리 캐시 계층을 함께 활용하는 하이브리드 접근법도 흔히 사용됩니다.

이 방식은 데이터의 영속성이 필수적인 사용자 세션 저장(장기 세션), 사용자 프로필 정보, 대규모 객체 메타데이터 저장, 그리고 메인 데이터베이스의 백업 저장소 등에 널리 사용됩니다. 최근에는 NVMe SSD의 보급으로 디스크 기반 시스템의 지연 시간과 처리량이 크게 개선되고 있습니다.

분산 키-값 저장소는 여러 대의 서버에 데이터를 분산하여 저장하고 관리하는 키 값 저장소이다. 단일 서버의 용량과 성능 한계를 극복하고, 가용성과 내결함성을 높이는 것을 주요 목표로 한다. 데이터는 파티셔닝 또는 샤딩 기법을 통해 여러 노드에 나누어 저장되며, 클라이언트 요청은 적절한 노드로 라우팅된다.

이러한 시스템은 일반적으로 일관성, 가용성, 파티션 허용성의 세 가지 속성 사이의 트레이드오프를 다루는 CAP 정리를 실천의 근간으로 삼는다. 시스템 설계 시 강한 일관성을 보장하거나, 높은 가용성을 우선시하는 등 목표에 따라 다른 접근 방식을 취한다. 데이터의 복제는 가용성과 내결함성을 위해 필수적이며, 다중 리더 복제나 단일 리더 복제 등의 방식을 사용한다.

분산 환경에서의 주요 기술적 과제와 그 해결 방안은 다음과 같이 정리할 수 있다.

이러한 시스템은 대규모 웹 서비스, 마이크로서비스 아키텍처 환경의 설정 저장소, 실시간 추천 시스템 등에서 널리 사용된다. Amazon DynamoDB, etcd, Apache Cassandra 등이 대표적인 예시이다.

Redis는 오픈 소스 인메모리 키-값 저장소이다. 주로 데이터베이스, 캐시, 메시지 브로커로 사용된다. 문자열, 리스트, 해시, 셋, 정렬된 셋과 같은 다양한 데이터 구조를 지원하는 것이 주요 특징이다. 모든 데이터를 주 메모리에 저장하여 매우 빠른 읽기와 쓰기 성능을 제공한다.

Redis는 지속성을 옵션으로 제공한다. 기본적으로 모든 데이터는 메모리에 상주하지만, 스냅샷(RDB 파일)이나 추가 전용 파일(AOF)을 디스크에 저장하여 서버 재시작 후 데이터를 복구할 수 있다. 또한 마스터-슬레이브 복제를 지원하여 가용성과 읽기 성능을 높일 수 있다. Redis 클러스터를 구성하면 데이터를 여러 노드에 자동으로 분산하여 샤딩과 고가용성을 달성한다.

주요 사용 사례로는 세션 저장, 캐싱, 실시간 순위표, 작업 큐, 게시/구독 메시징 등이 있다. 단일 스레드 아키텍처를 기반으로 하여 원자적 연산을 보장하며, 뛰어난 성능으로 인해 많은 웹 애플리케이션의 핵심 인프라 구성 요소로 자리 잡았다.

Amazon DynamoDB는 아마존 웹 서비스(AWS)가 제공하는 완전 관리형 NoSQL 키 값 저장소 서비스이다. 2007년에 처음 발표된 이 서비스는 가용성과 확장성을 핵심 설계 목표로 삼았으며, 아마존의 대규모 전자상거래 플랫폼의 요구 사항을 충족하기 위해 개발되었다. 서버리스 아키텍처를 채택하여 사용자는 인프라 관리 없이 데이터를 저장하고 조회할 수 있으며, 트래픽 패턴에 따라 자동으로 성능을 확장하거나 축소한다.

DynamoDB의 데이터 모델은 기본적으로 키-값 구조를 따르지만, 각 항목(Item)이 여러 속성(Attribute)을 가질 수 있는 문서 모델의 특징도 함께 지닌다. 주요 키(Primary Key)로는 단일 파티션 키(Partition Key) 또는 파티션 키와 정렬 키(Sort Key)의 조합인 복합 키(Composite Key)를 사용한다. 이는 효율적인 데이터 접근과 정렬된 쿼리를 가능하게 한다. 또한, 글로벌 보조 인덱스(GSI)와 로컬 보조 인덱스(LSI)를 지원하여 다양한 쿼리 패턴을 유연하게 처리한다.

DynamoDB는 ACID 트랜잭션을 지원하며, TTL 기능을 통해 항목의 자동 만료를 설정할 수 있다. 또한, 변경 데이터 캡처 스트림(DynamoDB Streams)을 제공하여 항목의 수정 사항을 실시간으로 캡처하고 이를 AWS Lambda 함수 등 다른 서비스와 연동하는 것이 가능하다. 이러한 특징들로 인해 DynamoDB는 사용자 프로필, 게임 데이터, IoT 데이터, 캐싱 등 다양한 대규모 애플리케이션의 백엔드 저장소로 널리 사용된다.

etcd는 고가용성을 갖춘 분산 키 값 저장소로, 분산 시스템에서 구성 데이터를 안정적으로 저장하고 관리하기 위해 설계되었다. CoreOS가 개발을 시작했으며, 현재는 클라우드 네이티브 컴퓨팅 재단(CNCF)의 졸업 프로젝트이다. 주된 용도는 분산 시스템의 구성 관리, 서비스 디스커버리, 그리고 분산 조정(코디네이션)이다.

etcd는 Raft 합의 알고리즘을 구현하여 강력한 일관성을 보장한다. 이는 클러스터 내 여러 노드에 데이터를 복제하고, 모든 쓰기 연산이 대다수 노드에 성공적으로 기록되어야 클라이언트에 성공으로 응답함을 의미한다. 이러한 특성 덕분에 시스템의 상태 정보와 같은 중요한 데이터를 안전하게 저장하는 데 적합하다. 데이터 모델은 계층적인 키 공간을 제공하며, 각 키는 버전 히스토리를 유지한다.

주요 사용 사례로는 쿠버네티스의 백엔드 저장소가 대표적이다. 쿠버네티스는 모든 클러스터 상태(파드, 노드, 구성 정보 등)를 etcd에 저장한다. 또한, 서비스 디스커버리 구현, 분산 락 관리, 시스템 구성 파라미터의 중앙 집중식 저장에도 널리 사용된다. gRPC 기반의 API를 제공하며, JSON 또는 YAML 형식의 데이터를 저장할 수 있다.

키 값 저장소는 캐싱 계층을 구현하는 데 매우 효율적인 도구이다. 캐싱은 자주 접근하는 데이터를 빠른 저장 매체에 임시로 보관하여, 느린 백엔드 데이터베이스나 외부 서비스에 대한 요청 수를 줄이고 응답 시간을 단축하는 기법이다.

키 값 저장소는 단순한 키와 값 구조 덕분에 매우 빠른 읽기와 쓰기 성능을 제공한다. 이는 인메모리 방식으로 구현된 Redis와 같은 시스템에서 특히 두드러진다. 데이터베이스 쿼리 결과, API 응답, 렌더링된 웹 페이지 조각(HTML) 등을 고유한 키와 함께 저장해두면, 이후 동일한 요청이 들어왔을 때 복잡한 계산이나 데이터베이스 조회 없이 저장된 값을 즉시 반환할 수 있다.

캐싱 전략은 주로 TTL (Time-To-Live) 설정과 함께 사용된다. TTL은 각 데이터 항목에 수명을 부여하여, 일정 시간이 지나면 자동으로 캐시에서 삭제되게 한다. 이는 데이터의 신선도를 유지하는 데 필수적이다. 캐시 무효화 전략은 애플리케이션의 요구사항에 따라 다양하게 설계된다.

효과적인 캐싱은 백엔드 시스템의 부하를 현저히 낮추고, 애플리케이션의 전반적인 처리량과 사용자 경험을 향상시킨다. 다만, 캐시와 원본 데이터 간의 일관성 모델 문제와 캐시 장애 시의 대비책(예: 캐시 미스 시나리오)을 신중하게 고려해야 한다.

세션 저장은 키 값 저장소의 대표적인 사용 사례 중 하나이다. 웹 애플리케이션은 일반적으로 HTTP의 무상태(Stateless) 특성을 보완하기 위해 사용자의 상태 정보를 세션에 저장한다. 이 세션 데이터를 관리하는 데 키 값 저장소가 적합하게 활용된다.

세션 데이터는 일반적으로 세션 ID를 키로, 사용자의 로그인 상태, 장바구니 정보, 임시 설정값 등을 값으로 저장한다. 이 데이터는 빠른 읽기와 쓰기가 필수적이며, 구조가 단순하고 일정 시간 후 자동으로 삭제되는 TTL 기능이 유용하게 적용된다. 인메모리 방식의 Redis와 같은 시스템은 이러한 요구사항에 잘 부합하여 널리 사용된다.

세션 저장을 위해 키 값 저장소를 선택할 때는 읽기/쓰기 성능, 데이터의 내구성 요구사항, 시스템의 확장성, 그리고 비용을 종합적으로 고려해야 한다. 또한, 모든 사용자 세션을 단일 저장소에 의존하지 않도록 장애 조치와 복제 전략을 마련하는 것이 중요하다.

사용자 프로필 정보는 키 값 저장소의 대표적인 사용 사례 중 하나이다. 각 사용자를 고유하게 식별하는 사용자 ID나 세션 토큰을 키로, 해당 사용자의 프로필 데이터를 값으로 저장하는 구조이다. 프로필 데이터는 JSON이나 Protocol Buffers 같은 직렬화 형식으로 구조화된 정보를 포함할 수 있다.

이러한 방식은 읽기와 쓰기가 빈번하게 발생하는 사용자 데이터에 매우 효율적이다. 단일 키에 대한 조회나 업데이트 연산은 매우 빠르게 수행된다. 또한, 스키마가 고정되어 있지 않기 때문에, 애플리케이션 요구사항이 변경되어 새로운 프로필 필드가 추가되더라도 유연하게 대응할 수 있다는 장점이 있다.

사용자별 애플리케이션 설정이나 선호도 저장에도 널리 활용된다. 예를 들어, 테마 색상, 언어 설정, 알림 옵션, 최근 활동 기록 등과 같은 데이터를 키-값 쌍으로 관리한다. 이러한 설정은 종종 TTL (Time-To-Live)이 설정되지 않고 영구적으로 보관되며, 사용자 경험을 개인화하는 데 중요한 역할을 한다.

대규모 서비스에서는 모든 사용자 프로필을 단일 저장소에 보관하기보다, 사용 빈도나 데이터 특성에 따라 여러 저장소를 조합하여 사용하기도 한다. 예를 들어, 활성 사용자의 핵심 프로필은 Redis 같은 인메모리 방식 저장소에 캐싱하여 빠르게 응답하고, 전체 데이터는 Amazon DynamoDB나 디스크 기반 저장소에 영구 보관하는 아키텍처를 구성한다.

TTL은 키 값 저장소에서 특정 데이터 항목의 수명을 제한하는 데 사용되는 메커니즘이다. 이 기능은 저장된 키와 값의 쌍에 만료 시간을 설정하여, 해당 시간이 지나면 시스템이 자동으로 데이터를 삭제하거나 무효화하도록 한다. TTL 값은 일반적으로 초 단위로 지정되며, 데이터를 생성하거나 업데이트할 때 설정된다.

TTL의 주요 사용 목적은 데이터의 자동 정리와 저장 공간의 효율적 관리이다. 특히 캐싱이나 세션 저장과 같이 일시적인 데이터를 다루는 사용 사례에서 유용하게 활용된다. 예를 들어, 사용자 로그인 세션 정보에 30분의 TTL을 설정하면, 30분 후에는 해당 세션 데이터가 자동으로 삭제되어 오래된 정보가 누적되는 것을 방지한다. 이는 시스템의 메모리나 디스크 공간을 확보하고, 데이터 일관성을 유지하는 데 도움을 준다.

구현 방식에 따라 TTL의 동작은 다를 수 있다. 일부 시스템은 데이터가 만료되자마자 즉시 삭제하는 반면, 다른 시스템은 주기적인 스윕(sweep) 작업을 통해 만료된 데이터를 일괄 처리하기도 한다. 또한, TTL이 설정된 데이터에 대한 읽기 요청 시, 시스템은 내부적으로 만료 여부를 확인하고 만료된 데이터는 사용자에게 반환하지 않는다.

TTL 기능은 Redis나 Amazon DynamoDB와 같은 많은 현대적인 키-값 저장소에서 표준으로 제공된다. 이 기능을 적절히 활용하면 애플리케이션 로직을 단순화하고, 데이터 관리 부담을 줄이며, 시스템의 전반적인 성능과 안정성을 높일 수 있다.

키 값 저장소는 전통적인 관계형 데이터베이스와 달리 복잡한 트랜잭션과 강력한 일관성을 기본으로 제공하지 않는다. 대신, 분산 환경에서의 가용성과 성능을 위해 다양한 일관성 모델을 채택한다. 이 모델들은 CAP 정리의 개념과 밀접하게 연관되어 있으며, 시스템 설계 시 일관성, 가용성, 분할 내성 중 어떤 것을 우선시할지에 따라 선택된다.

가장 흔한 모델은 최종 일관성이다. 이 모델에서는 데이터의 갱신이 모든 복제본에 즉시 동기화되지 않을 수 있다. 쓰기 연산 후 일정 시간 동안은 다른 노드에서 이전 데이터를 읽을 가능성이 있지만, 새로운 쓰기가 없는 상태에서 충분한 시간이 지나면 모든 복제본이 동일한 최신 값으로 수렴한다. 이 방식은 높은 가용성과 낮은 지연 시간을 제공하지만, 강한 일관성이 필요한 작업에는 적합하지 않다. 반면, 강한 일관성 모델은 모든 읽기 연산이 가장 최근에 완료된 쓰기 연산의 결과를 반환하도록 보장한다. 이는 단일 시스템처럼 동작하지만, 네트워크 지연이나 장애로 인해 가용성이 희생될 수 있다.

다른 모델들도 특정 요구사항을 충족하기 위해 존재한다. 일관된 접두사 읽기는 클라이언트가 데이터의 일관성이 깨진 상태를 보지 않도록, 쓰기가 발생한 순서대로 데이터를 읽을 수 있게 보장한다. 세션 일관성은 특정 클라이언트 세션 내에서 읽기 일관성을 유지하는 모델이다. 시스템 설계자는 애플리케이션의 요구사항에 따라 적절한 일관성 수준을 선택해야 한다. 예를 들어, 사용자 세션 데이터는 최종 일관성으로도 충분할 수 있지만, 재고 관리나 금융 거래와 같은 데이터는 강한 일관성이 필수적일 수 있다.

데이터 양이 증가하여 단일 서버의 용량이나 처리 성능을 초과할 때, 데이터를 여러 서버에 분산하여 저장하고 관리하기 위해 파티셔닝과 샤딩 기법을 사용한다. 두 용어는 종종 혼용되지만, 파티셔닝은 데이터를 논리적 또는 물리적으로 나누는 일반적인 개념이며, 샤딩은 수평 파티셔닝의 한 형태로, 데이터를 여러 데이터베이스 인스턴스나 서버에 분산시키는 특정 구현 방식을 가리킨다.

파티셔닝의 주요 방법은 키 범위 기반 파티셔닝과 해시 기반 파티셔닝이다. 키 범위 기반 파티셔닝은 연속적인 키 범위를 각 파티션에 할당하는 방식이다. 예를 들어, 사용자 ID가 'a'부터 'm'까지는 파티션 1에, 'n'부터 'z'까지는 파티션 2에 저장할 수 있다. 이 방식은 범위 쿼리에 효율적이지만, 데이터 분포가 고르지 않으면 특정 파티션에 부하가 집중되는 핫스팟 현상이 발생할 수 있다. 해시 기반 파티셔닝은 키에 해시 함수를 적용하여 얻은 값을 기준으로 데이터를 분배한다. 이는 데이터를 비교적 균일하게 분산시켜 핫스팟을 줄이지만, 연속적인 키 범위에 대한 효율적인 쿼리가 불가능해진다는 단점이 있다.

샤딩을 구현할 때는 데이터의 균등한 분배, 클러스터 노드의 추가/제거 시 데이터 재배치(리샤딩)의 효율성, 그리고 클라이언트가 요청을 올바른 샤드로 라우팅할 수 있도록 하는 방법이 중요 고려사항이다. 일관성 해싱은 노드의 추가나 제거 시 재배치해야 하는 데이터의 양을 최소화하는 데 널리 사용되는 기술이다[2]. 또한, 복제 기법과 결합하여 가용성과 내결함성을 높이는 경우가 많다.