Bigtable (r1)

Bigtable의 데이터 모델은 전통적인 관계형 데이터베이스와는 구별되는 단순하면서도 강력한 구조를 가진다. 이 모델은 행(Row), 열(Column), 타임스탬프(Timestamp)라는 세 가지 기본 차원으로 데이터를 구성한다. 각 데이터 항목은 이러한 3차원 좌표에 의해 고유하게 식별되며, 이는 스키마가 유연하고 대규모 데이터를 효율적으로 저장 및 조회할 수 있는 기반이 된다.

구체적으로, 모든 데이터는 행 키(Row Key)로 정렬되어 저장된다. 행 키는 임의의 문자열이며, 이 키를 기준으로 데이터가 사전식 순서로 정렬되어 분산 저장된다. 이는 범위 스캔과 같은 조회 작업을 매우 효율적으로 만든다. 하나의 행은 여러 개의 열 패밀리(Column Family)를 포함할 수 있으며, 각 열 패밀리 아래에는 여러 개의 열 한정자(Column Qualifier)가 존재한다. 열 패밀리는 데이터의 의미론적 그룹을 나타내며, 저장소 최적화의 기본 단위로 사용된다.

각 셀(Cell)은 행 키, 열 패밀리, 열 한정자로 지정되며, 여기에 타임스탬프 차원이 더해져 여러 버전의 값을 가질 수 있다. 타임스탬프는 일반적으로 마이크로초 단위의 시스템 시간이며, 이를 통해 동일한 셀에 대한 역사적 데이터를 보존하고 관리할 수 있다. 이 구조는 웹 인덱싱, 사용자 행동 로그, 시계열 데이터와 같이 시간에 따라 변하는 대량의 데이터를 처리하는 데 특히 적합하다.

이러한 데이터 모델은 구글의 다양한 서비스, 예를 들어 구글 웹 검색의 인덱스 저장, 구글 지도의 지리 공간 데이터 처리, Gmail의 메타데이터 관리 등에 적용되어 그 실용성을 입증했다. Bigtable은 완전한 관계형 데이터베이스 관리 시스템이 아니며, 복잡한 다중 행 트랜잭션이나 풍부한 조인 연산을 지원하지 않는다. 대신, 단일 행 키에 대한 고성능 조회와 범위 스캔에 최적화된 간결한 모델을 제공함으로써 빅데이터 환경에서의 확장성과 성능 요구를 충족시킨다.

Bigtable은 구글의 대규모 인프라 위에서 동작하는 분산 저장 시스템이다. 하나의 거대한 테이블이 수천 대의 서버에 걸쳐 분산되어 저장되며, 이를 통해 페타바이트 규모의 데이터를 처리할 수 있다. 데이터는 행 키를 기준으로 정렬되어 여러 태블릿이라는 단위로 나뉘어 저장된다. 각 태블릿은 연속된 행 범위를 담당하는 데이터 조각으로, 시스템의 기본 분산 및 부하 분산 단위가 된다.

이러한 태블릿들은 클러스터를 이루는 여러 서버에 분산 배치된다. 시스템의 핵심 구성 요소인 마스터 서버는 태블릿의 위치 정보를 관리하고 태블릿 할당을 조정하는 반면, 실제 데이터의 읽기와 쓰기 요청은 태블릿 서버가 직접 처리한다. 데이터의 지속성과 고가용성을 보장하기 위해 모든 변경 사항은 먼저 커밋 로그에 기록된 후, 메모리 버퍼에 캐시된다. 메모리 버퍼가 가득 차면 디스크에 SSTable이라는 불변의 정렬된 파일 형식으로 플러시된다.

분산 구조의 관리와 조정을 위해 Bigtable은 구글 파일 시스템과 같은 분산 파일 시스템을 하위 저장소로 활용하며, Chubby라는 분산 잠금 서비스를 통해 마스터 선출, 부트스트랩, 스키마 정보 저장 등의 클러스터 관리 작업을 수행한다. 이로 인해 시스템은 서버 장애가 발생하더라도 다른 서버가 해당 태블릿을 빠르게 인계받아 서비스를 계속할 수 있는 탄력성을 갖는다.

Bigtable의 구성 요소는 크게 클라이언트 라이브러리, 마스터 서버, 태블릿 서버, 그리고 구글 파일 시스템과 Chubby 분산 잠금 서비스로 나뉜다. 클라이언트 라이브러리는 애플리케이션이 Bigtable과 통신하기 위한 인터페이스를 제공하며, 데이터를 직접 마스터 서버가 아닌 태블릿 서버와 통신하도록 설계되어 시스템의 병목 현상을 방지한다.

시스템의 중앙 관리 역할을 하는 마스터 서버는 태블릿 서버의 상태를 모니터링하고, 태블릿의 할당 및 재분배, 가비지 컬렉션과 같은 메타데이터 작업을 담당한다. 그러나 클라이언트의 데이터 읽기 및 쓰기 요청은 직접 처리하지 않아 시스템의 확장성과 성능을 유지한다. 실제 데이터 입출력 작업은 태블릿 서버가 처리한다.

태블릿 서버는 데이터의 기본 저장 단위인 태블릿을 관리하며, 각 태블릿 서버는 일반적으로 수십에서 수백 개의 태블릿을 호스팅한다. 이 서버들은 구글 파일 시스템에 데이터를 지속적으로 저장하고, 메모리 내 캐시인 멤테이블을 통해 빠른 쓰기 성능을 제공한다. 또한 Chubby 서비스는 마스터 서버의 선출, 태블릿 서버의 등록, 스키마 정보 저장 등의 중요한 분산 조정 기능을 수행하여 시스템의 가용성과 일관성을 보장한다.

Bigtable은 수천 대의 상용 서버로 구성된 클러스터에서 실행되도록 설계되어 페타바이트 규모의 데이터를 처리할 수 있다. 이는 구글의 검색 색인, 지메일, 구글 지도와 같은 대규모 서비스의 데이터 저장 요구를 충족시키기 위한 핵심이다. 시스템은 새로운 서버를 클러스터에 추가하는 방식으로 수평적 확장이 가능하며, 데이터 증가에 따라 용량을 거의 선형적으로 늘릴 수 있다.

확장성의 핵심은 데이터를 여러 태블릿 서버에 분산하여 저장하는 샤딩 메커니즘에 있다. 각 태블릿은 연속된 행 범위를 담당하며, 데이터 양이 증가하면 하나의 태블릿이 분할되어 부하가 새로운 서버로 재분배된다. 이 과정은 자동으로 이루어져 관리자의 개입 없이도 시스템이 대용량 데이터와 높은 트래픽을 처리할 수 있도록 보장한다.

이러한 아키텍처 덕분에 Bigtable은 클라우드 컴퓨팅 환경에서 빅데이터 분석, 시계열 데이터 저장, 머신러닝 모델 서빙과 같은 다양한 대규모 작업에 적합한 저장소로 사용된다. 구글 클라우드의 관리형 서비스인 Cloud Bigtable을 통해 외부 사용자들도 동일한 확장성과 성능을 활용할 수 있게 되었다.

Bigtable의 성능은 대규모 데이터 처리에 최적화된 설계에서 비롯된다. 높은 처리량과 낮은 지연 시간을 동시에 달성하는 것이 핵심 목표이며, 이를 위해 데이터를 메모리와 디스크에 효율적으로 배치하고, 읽기 및 쓰기 연산을 최적화한다. 특히, 자주 접근하는 데이터는 메모리 기반의 SSTable 캐시에 보관하여 빠르게 응답하고, 쓰기 작업은 먼저 커밋 로그에 기록한 후 메모리 테이블에 버퍼링하여 디스크 I/O를 최소화한다.

성능을 유지하는 데 중요한 요소는 압축과 로드 밸런싱이다. Bigtable은 주기적으로 여러 SSTable 파일을 병합하고 압축하여 디스크 공간을 절약하고, 읽기 성능을 향상시킨다. 또한, 데이터가 여러 태블릿 서버에 분산 저장되며, 마스터 서버는 태블릿의 재배치를 통해 각 서버의 부하를 균등하게 분산시켜 성능 저하를 방지한다. 이러한 설계는 구글의 검색 색인, 지메일, 구글 지도와 같은 대규모 서비스에서 안정적인 성능을 제공하는 기반이 된다.

Bigtable은 높은 가용성을 보장하기 위해 설계된 분산 시스템이다. 이는 시스템의 핵심 구성 요소가 단일 장애점이 되지 않도록 하는 구조와 데이터의 다중 복제를 통해 달성된다. 데이터는 여러 데이터 센터에 걸쳐 복제되어 저장되며, 하나의 서버나 데이터 센터 전체에 장애가 발생하더라도 다른 복제본을 통해 서비스가 중단 없이 계속될 수 있다. 이러한 설계는 구글의 핵심 서비스들이 24시간 중단 없이 운영되어야 한다는 요구사항을 충족시키는 데 필수적이다.

가용성을 유지하는 메커니즘은 장애 감지와 자동 복구에 있다. Bigtable 클러스터를 구성하는 서버들은 서로의 상태를 지속적으로 모니터링한다. 특정 서버에 장애가 발생하면, 시스템은 이를 빠르게 감지하고 해당 서버가 담당하던 데이터 범위와 작업을 다른 정상 서버들로 자동 재분배한다. 이 과정은 사용자나 애플리케이션에 거의 영향을 주지 않으며, 서비스 수준 계약에서 요구하는 높은 가용성 수준을 유지할 수 있게 한다.

이러한 고가용성 아키텍처는 Bigtable이 구글 내부의 검색 엔진, Gmail, 구글 지도와 같은 대규모 서비스의 백엔드 저장소로 신뢰성 있게 사용될 수 있는 기반이 된다. 또한, 클라우드 컴퓨팅 서비스인 Cloud Bigtable을 통해 외부 고객에게도 동일한 수준의 가용성을 제공하고 있다.

Bigtable은 강력한 일관성 모델을 제공한다. 이는 모든 클라이언트가 동일한 데이터의 최신 복사본을 읽을 수 있음을 보장한다. 이 일관성은 단일 행 내의 모든 작업에 대해 적용되며, 이는 하나의 행 키에 대한 읽기와 쓰기 작업이 선형화 가능성을 따름을 의미한다. 이러한 설계는 구글의 많은 핵심 서비스가 실시간으로 정확한 데이터에 접근해야 하는 요구사항에 부합한다.

그러나 Bigtable의 일관성 보장은 여러 행이나 테이블에 걸친 트랜잭션을 기본적으로 지원하지 않는다. 즉, 서로 다른 행에 대한 여러 쓰기 작업이 원자적으로 수행되지 않을 수 있다. 이는 대규모 분산 시스템에서 높은 처리량과 낮은 지연 시간을 유지하기 위한 설계적 선택이다. 복잡한 다중 행 업데이트가 필요한 경우, 애플리케이션 레벨에서 추가적인 로직을 구현해야 한다.

Bigtable의 일관성 모델은 CAP 정리의 관점에서 볼 때, 분할 내성(Partition tolerance)과 강한 일관성(Consistency)을 우선시하는 CP 시스템에 가깝다. 가용성(Availability)은 네트워크 분할 상황에서 일관성을 위해 일부 희생될 수 있다. 이는 금융 기록이나 검색 색인과 같이 데이터 정확성이 매우 중요한 빅데이터 처리 시나리오에 적합한 특성이다.

Bigtable의 읽기와 쓰기 프로세스는 시스템의 핵심 성능과 일관성을 보장하는 설계 원칙을 반영한다. 클라이언트는 주로 구글의 내부 API를 통해 Bigtable에 접근하며, 데이터는 로우 키를 기준으로 정렬되어 여러 태블릿 서버에 분산 저장된다.

쓰기 작업이 발생하면 데이터는 먼저 커밋 로그에 기록되어 내구성을 확보한 후, 메모리 버퍼인 멤테이블에 저장된다. 멤테이블이 일정 크기에 도달하면 디스크에 SSTable이라는 불변의 정렬된 파일 형식으로 플러시된다. 이 과정에서 기존 SSTable 파일은 수정되지 않고 새로운 파일이 생성되며, 이후 다수의 SSTable 파일은 백그라운드에서 압축 과정을 통해 병합된다. 이 설계는 쓰기 성능을 높이고 디스크의 임의 쓰기를 최소화한다.

읽기 작업은 로우 키를 기반으로 해당 데이터를 담당하는 태블릿 서버를 찾아 진행된다. 클라이언트는 먼저 마스터 서버와 통신하지 않고, 태블릿 서버 위치 정보를 캐싱하는 클라이언트 라이브러리를 사용한다. 읽기 요청을 받은 태블릿 서버는 가장 최신 데이터부터 조회하기 위해, 메모리 상의 멤테이블과 디스크 상의 여러 SSTable 파일을 병합하여 결과를 반환한다. 이때 블룸 필터를 활용해 특정 SSTable에 원하는 데이터가 존재하지 않을 가능성을 빠르게 판단하여 불필요한 디스크 접근을 줄인다.

이러한 읽기/쓰기 프로세스는 높은 처리량과 낮은 지연 시간을 동시에 지원하도록 최적화되어 있다. 쓰기는 순차적 로그 기록과 메모리 버퍼링을 통해 고속 처리가 가능하며, 읽기는 데이터의 지역성을 활용한 캐싱과 효율적인 검색 구조를 통해 성능을 유지한다. 시스템의 상태 변화, 예를 들어 태블릿 서버의 장애나 부하 재분배는 마스터 서버에 의해 관리되며, 이 과정에서도 클라이언트의 읽기/쓰기 작업은 중단되지 않고 지속될 수 있다.

Bigtable은 대규모 데이터를 효율적으로 저장하기 위해 여러 단계의 압축 기법을 사용한다. 데이터는 우선 메모리 내의 멤테이블(MemTable)에 기록되며, 이는 정렬된 상태로 유지된다. 멤테이블이 일정 크기에 도달하면 불변성(immutable)을 가지는 SSTable(Sorted String Table) 파일 형식으로 디스크에 기록된다. 이 과정에서 데이터는 이미 기본적인 정렬과 압축의 이점을 가진다.

주요 압축은 SSTable 파일들 간에 발생한다. 시스템은 여러 개의 SSTable 파일을 주기적으로 병합하는 마이너 컴팩션(minor compaction)과 메이저 컴팩션(major compaction)을 수행한다. 마이너 컴팩션은 소수의 최근 SSTable들을 하나로 합치는 과정이며, 메이저 컴팩션은 모든 SSTable을 하나로 병합하여 최종 상태를 만든다. 이 과정에서 중복되거나 삭제 표시된 데이터가 제거되며, 데이터는 보다 조밀하게 재구성된다. 또한 SSTable 내부의 데이터 블록은 압축 알고리즘을 적용하여 디스크 사용 공간을 추가로 줄인다.

이러한 다단계 압축 전략은 저장 공간을 절약하는 것 외에도 읽기 성능을 향상시키는 핵심 역할을 한다. 여러 SSTable에 흩어져 있던 데이터가 하나의 파일로 통합되면, 읽기 작업 시 검색해야 할 파일의 수가 줄어들기 때문이다. 결과적으로 Bigtable은 방대한 양의 데이터를 상대적으로 적은 저장소 리소스로 관리하면서도 빠른 조회 성능을 유지할 수 있다.

로드 밸런싱은 Bigtable이 대규모 데이터와 요청을 균등하게 처리하며 시스템의 효율성과 안정성을 유지하는 핵심 메커니즘이다. Bigtable은 테이블을 여러 태블릿으로 분할하여 저장하며, 이 태블릿들은 클러스터 내의 수많은 서버에 분산 배치된다. 마스터 서버는 각 서버의 부하를 지속적으로 모니터링하여 특정 서버에 태블릿이 과도하게 집중되거나 요청 처리량이 많아지는 것을 방지한다. 이를 통해 개별 서버의 과부하를 예방하고, 클러스터 전체의 자원 활용도를 최적화하여 처리 성능을 균일하게 유지한다.

로드 밸런싱은 크게 두 가지 상황에서 활발히 작동한다. 첫째는 새로운 서버가 클러스터에 추가되거나 기존 서버가 제거될 때이다. 마스터 서버는 이러한 변화를 감지하고, 태블릿을 재배치하여 모든 서버에 걸쳐 데이터와 부하를 다시 균형 있게 분배한다. 둘째는 특정 태블릿에 대한 접근 패턴이 변화하여 해당 태블릿을 호스팅하는 서버에 부하가 집중될 때이다. 이 경우 마스터 서버는 해당 태블릿을 다른 여유 자원이 더 많은 서버로 이동시켜 핫스팟을 해소한다.

이러한 동적 로드 밸런싱은 확장성과 가용성을 보장하는 데 필수적이다. 사용량이 증가하면 서버를 추가하기만 하면 시스템이 자동으로 부하를 분산시켜 처리 용량을 늘릴 수 있다. 반대로 서버에 장애가 발생하면 해당 서버가 담당하던 태블릿들은 다른 정상 서버들로 빠르게 재배치되어 서비스 중단 없이 운영을 계속할 수 있다. 이 메커니즘은 구글의 다양한 대규모 서비스가 예측 불가능한 트래픽 변동 속에서도 안정적인 성능을 제공할 수 있게 하는 기반이 된다.

구글은 Bigtable을 자사의 핵심 서비스에 광범위하게 적용하여 대규모 데이터를 처리하고 있다. 대표적으로 구글 검색은 웹 색인 데이터를 Bigtable에 저장하여 빠른 검색 결과 제공을 뒷받침한다. 또한 지메일은 사용자별 메일 데이터와 첨부 파일 메타데이터를, 구글 지도는 지리 공간 데이터와 타일 이미지 정보를 Bigtable에 저장하여 신속한 접근과 처리를 가능하게 한다.

이 외에도 구글 애널리틱스는 웹사이트 트래픽 로그를, 구글 어스는 위성 이미지 및 지형 데이터를 Bigtable을 통해 관리한다. 유튜브 또한 채널 정보, 사용자 설정, 메타데이터 저장 등에 Bigtable을 활용하는 것으로 알려져 있다. 이러한 적용 사례는 Bigtable이 검색, 이메일, 지도 서비스, 콘텐츠 관리 등 다양한 도메인에서 페타바이트 규모의 데이터를 안정적으로 처리할 수 있는 확장성을 입증한다.

구글 내부에서 Bigtable은 단일한 범용 저장소라기보다, 각 서비스의 특정 데이터 저장 요구사항에 맞춰 최적화된 백엔드 저장소 역할을 수행한다. 이는 서비스마다 데이터 접근 패턴, 일관성 요구 수준, 처리량이 다르기 때문이다. Bigtable의 유연한 데이터 모델과 높은 처리량은 이러한 다양한 요구를 충족시키는 데 기여했다.

구글은 내부적으로 사용하던 빅테이블 기술을 클라우드 컴퓨팅 서비스 형태로 외부에 공개했다. 이 서비스의 명칭은 구글 클라우드 플랫폼의 일부인 Cloud Bigtable이다. 이를 통해 기업과 개발자들은 구글의 글로벌 인프라를 기반으로 빅테이블의 고성능과 확장성을 직접 활용할 수 있게 되었다. 사용자는 서버를 직접 관리할 필요 없이 완전 관리형 서비스로 데이터베이스를 운영할 수 있다.

Cloud Bigtable은 구글의 다른 클라우드 서비스들과 긴밀하게 통합되어 있다. 예를 들어, 빅쿼리를 사용한 분석 작업이나 데이터플로를 통한 데이터 처리 파이프라인에서 손쉽게 데이터를 주고받을 수 있다. 또한, 구글 클라우드 스토리지와의 연동을 통해 데이터 백업 및 복원이 용이하다. 이러한 통합성은 클라우드 네이티브 애플리케이션을 구축하는 데 큰 장점으로 작용한다.

이 서비스는 특히 대규모 빅데이터 분석, 머신러닝, 사물인터넷 애플리케이션에 적합하다. 짧은 지연 시간과 높은 처리량을 요구하는 실시간 서비스, 예를 들어 금융 거래 데이터 처리, 디지털 광고 분석, 게임 사용자 기록 저장 등에 널리 사용된다. 사용량에 따라 스토리지와 처리 능력을 독립적으로 확장할 수 있어 예측하기 어려운 워크로드에도 유연하게 대응할 수 있다.

HBase는 구글의 Bigtable 논문에 기반하여 개발된 오픈소스 분산 데이터베이스이다. 아파치 하둡 프로젝트의 일부로, HDFS 위에서 동작하며 대규모 구조화 데이터를 저장하고 관리하는 데 특화되어 있다. Bigtable의 핵심 설계 개념인 컬럼 패밀리, 타임스탬프, 분산 파일 시스템 기반 저장 등을 구현하여, 오픈소스 커뮤니티에 Bigtable과 유사한 기능을 제공하는 것이 주요 목표였다.

HBase의 데이터 모델은 Bigtable과 매우 유사하다. 데이터는 행 키, 컬럼 패밀리, 컬럼 한정자, 타임스탬프로 구성되며, 다중 버전 데이터를 저장할 수 있다. HBase 마스터 서버는 리전 서버를 관리하고 메타데이터를 조정하며, 실제 데이터의 읽기와 쓰기 작업은 각 리전을 담당하는 리전 서버가 처리한다. 이는 Bigtable의 마스터 서버와 태블릿 서버 구조에 대응한다.

HBase는 주로 하둡 에코시스템 내에서 실시간 읽기/쓰기 접근이 필요한 빅데이터 애플리케이션에 사용된다. 예를 들어, 웹 인덱싱, 메시징 시스템, 로그 분석 플랫폼 등에서 데이터 저장소로 활용된다. Bigtable이 구글의 내부 인프라에 최적화되어 있다면, HBase는 아파치 생태계와의 통합 및 오픈소스 진영의 유연성을 주요 장점으로 한다.

카산드라는 아파치 소프트웨어 재단에서 관리하는 오픈소스 분산형 NoSQL 데이터베이스 관리 시스템이다. 구글의 빅테이블과 아마존의 다이나모의 설계 개념을 결합하여 개발되었다. 페이스북이 초기 개발에 참여했으며, 높은 가용성과 확장성을 핵심 목표로 한다. 이는 단일 장애점이 없는 피어 투 피어 아키텍처를 채택하여, 수백 대의 서버에 걸쳐 데이터를 분산 저장하고 복제할 수 있다.

카산드라의 데이터 모델은 컬럼 패밀리 기반으로, 빅테이블의 영향을 받았지만, 키-값 저장소의 특성도 함께 지닌다. 각 로우는 고유한 로우 키로 식별되며, 컬럼 기반으로 유연한 스키마를 지원한다. 쓰기와 읽기 성능 모두를 최적화하기 위해 설계되었으며, 특히 쓰기 작업에 매우 뛰어난 처리량을 보인다. 데이터 일관성 수준은 애플리케이션 요구에 따라 조정 가능한 튜닝 가능한 일관성 모델을 제공한다.

주요 특징으로는 선형적인 확장성, 다중 데이터센터 지원, 그리고 마스터리스 아키텍처를 통한 고가용성이 있다. 모든 노드가 동등한 역할을 하여 클러스터에 노드를 추가함으로써 용량과 처리량을 쉽게 늘릴 수 있다. 이러한 특성으로 인해 소셜 미디어, IoT, 실시간 분석 등 쓰기 집약적이고 대용량 데이터를 처리해야 하는 다양한 분야에서 널리 사용되고 있다.

Bigtable은 NoSQL 데이터베이스의 한 종류로, 특히 열 지향 데이터베이스에 속한다. 이와 유사한 목적을 가진 다른 주요 NoSQL 데이터베이스로는 HBase와 Cassandra가 있으며, 이들은 각각 다른 설계 철학과 특징을 가지고 있다. HBase는 Hadoop 생태계의 일부로, Bigtable의 오픈소스 구현체에 가깝다. 반면 Cassandra는 아마존 다이나모의 분산 설계와 Bigtable의 데이터 모델을 혼합한 형태로, 마스터리스 아키텍처를 채택하여 쓰기 성능과 가용성에 중점을 둔다.

이들 외에도 다양한 NoSQL 데이터베이스들이 존재한다. 문서 지향 데이터베이스인 MongoDB는 JSON과 유사한 형식의 문서를 저장하며, 유연한 스키마를 제공한다. 키-값 저장소의 대표주자인 Redis는 메모리 기반으로 매우 빠른 속도를 자랑하며 캐시나 세션 저장에 주로 사용된다. 그래프 데이터베이스인 Neo4j는 노드와 관계로 구성된 데이터를 효율적으로 처리하는 데 특화되어 있다.

각 NoSQL 데이터베이스는 데이터 모델, 일관성 모델, 분산 아키텍처, 그리고 사용 사례에 따라 명확한 차이점을 보인다. Bigtable은 대규모의 구조화된 데이터에 대한 높은 처리량과 낮은 지연 시간의 읽기/쓰기가 필요한 구글의 핵심 서비스에 최적화되어 있다. 따라서 프로젝트의 요구사항에 따라 적절한 데이터베이스 기술을 선택하는 것이 중요하다.