2019.11.13

‘질문 12개로 구성한’ 데이터베이스 선택 가이드

Martin Heller | InfoWorld

‘적절한’ 데이터베이스를 선택하는 것이 애플리케이션의 성공의 핵심이 될 수 있는 경우가 많다. 벤더의 조언을 듣거나 이미 있다는 이유로 데이터베이스를 사용하는 대신에 근본적인 데이터 저장의 목적과 요건을 고려하는 것이 좋다.

데이터베이스를 선택할 때 고려해야 할 중요한 질문은 다음과 같다.

- 애플리케이션이 성숙했을 때 얼마나 많은 데이터를 저장할 것으로 예상되는가?
- 첨두 부하(peak load)에서 동시에 몇 명의 사용자를 처리할 것으로 예상되는가?
- 애플리케이션에 필요한 가용성, 확장성, 지연 속도, 처리량, 데이터 일관성은 어느 정도인가?
- 데이터베이스 체계(schemas)는 얼마나 자주 바뀔 것인가?
- 사용자 인구의 지리적 분포는 어떠한가?
- 자연스러운 데이터의 ‘형태’는 무엇인가?
- 애플리케이션은 OLTP, OLAP 중 어떤 것을, 또는 모두를 필요로 하는가?
- 현실 속에서 기대하는 쓰기 대비 읽기의 비율은?
- 지리적 쿼리(Query) 또는 전체 텍스트 쿼리가 필요한가?
- 선호하는 프로그래밍 언어는 무엇인가?
- 예산이 있는가? 그렇다면 라이선스 및 지원 계약까지 포함시킬 수 있는가?
- 데이터 저장소에 대한 법적 한계가 있는가?

이 질문들의 의미를 살펴본다. 
 

ⓒ Image Credit : Getty Images Bank


어느 정도의 데이터를 저장할 것인가?
기가바이트 단위 이하의 수준으로 예상된다면 거의 모든 데이터베이스가 문제되지 않으며, 인-메모리 데이터베이스도 충분히 적용 가능하다. 테라바이트(Terabyte, 수천 기가바이트) 범위의 데이터베이스를 처리할 수 있는 데이터베이스 옵션도 많다.

페타바이트(Petabyte, 수백만 기가바이트) 이상의 수준이라면 사용할 수 있는 데이터베이스가 몇 개 없으며 구내 스토리지를 위한 자본 지출이나 클라우드 스토리지를 위한 운영 지출 등 상당한 데이터베이스 저장 비용에 대비해야 한다. 

이런 규모에서는 ‘라이브’ 데이터에 대한 쿼리는 속도를 위해 인-메모리나 로컬 SSD로 실행하고 전체 데이터 세트는 경제성을 위해 회전식 디스크에 보관하는 식의 단계화된 저장소 구조가 필요할 수 있다.

동시 사용자는 몇 명인가?
동시 사용자로부터 발생하는 부하를 추정하는 작업이 데이터베이스를 설치하기 직전에 서버 규모 설정 연습으로 치부되는 경우가 많다. 안타깝게도 많은 데이터베이스가 확장 문제를 가진다. 테라바이트 또는 페타바이트 단위의 데이터를 쿼리 처리하는 수천 명의 사용자를 처리할 수 없는 것이다.

동시 사용자를 예측하는 작업은 직원들이 사용하는 데이터베이스일 경우 훨씬 쉽다. 공개 데이터베이스의 경우 예상치 못하거나 계절적인 부하를 위해 여러 서버로 확장할 수 있는 옵션이 있어야 할 수 있다. 안타깝게도 대형 테이블의 수동 샤딩(sharding) 없이 수평적으로 확장할 수 있도록 지원하는 데이터베이스는 일부에 그친다. 

‘성격(-ility)’ 요건은 무엇인가?
가용성(availability), 확장성(scalability)과 같은 요건을 의미한다.  ‘성(-ility)’으로 끝나지 않는 레이턴시, 쓰루풋, 데이터 일관성(data consistency) 요건도 여기에 포함된다. 

가용성은 트랜잭션 데이터베이스의 핵심 기준인 경우가 많다. 모든 애플리케이션이 99.999%의 24/7 가용성이 필요한 것은 아니지만 그런 것들도 있다. 일부 클라우드 데이터베이스는 여러 가용성 구역에서 운영하는 한 ‘파이브 나인’(99.999%) 가용성을 제공한다. 구내 데이터베이스는 일반적으로 예약된 유지보수 기간 외에 높은 가용성에 맞추어 구성할 수 있으며, 활성-활성 서버쌍을 구성할 수 있다면 더욱 그렇다.

확장성, 특히 수평적 확장성은 역사적으로 NoSQL 데이터베이스가 SQL 데이터베이스보다 좋았다. 그러나 많은 SQL 데이터베이스가 따라잡고 있다. 동적 확장성은 클라우드에서 훨씬 쉽게 달성할 수 있다. 확장성이 좋은 데이터베이스는 부하 대비 처리량이 충분해질 때까지 확장함으로써 많은 동시 사용자를 처리할 수 있다.

레이턴시는 데이터베이스의 응답 시간과 애플리케이션의 E2E 응답 시간 모두를 의미한다. 모든 사용자 동작이 1초 미만의 응답 시간을 갖는 것이 이상적이며, 이를 위해서는 데이터베이스가 각각의 단순한 트랜잭션에 100밀리초 미만의 속도로 반응해야 하는 경우가 많다. 분석 쿼리는 수 초 또는 수 분이 소요될 수 있다. 애플리케이션은 복잡한 쿼리를 백그라운드로 수행하여 응답 시간을 아낄 수 있다.

OLTP 데이터베이스의 처리량(Throughput)은 일반적으로 초당 트랜잭션으로 측정된다. 처리량이 높은 데이터베이스는 많은 동시 사용자를 지원할 수 있다.

일반적으로 데이터 일관성은 SQL 데이터베이스에 ‘강력하다.’ 모든 읽기에서 최신 데이터가 반환된다. 데이터 일관성은 NoSQL 데이터베이스의 경우 ‘최종적’인 것부터 ‘엄격한’ 것까지 무엇이든 될 수 있다. 이벤트적 일관성(Eventual consistency)은 지연 속도를 낮추는 대신에 오래된 데이터를 읽을 위험이 있다.

한편 일관성은 오류, 네트워크 파티션, 정전 발생 시 유효성을 위해 필요한 ACID 속성 중 ‘C’에 해당된다. 4개의 ACID 속성은 Atomicity(원자성), Consistency(일관성), Isolation(고립), Durability(내구성)이다.

데이터베이스 체계는 안정적인가?
데이터베이스 체계가 시간이 지나도 크게 바뀔 가능성이 없고 대부분의 필드에서 레코드 간에 일관된 유형이 있기를 원한다면 SQL 데이터베이스가 좋은 선택일 것이다. 그렇지 않으면 (일부는 스키마를 지원조차 하지 않지만) NoSQL 데이터베이스가 애플리케이션에 더 좋을 수 있다. 하지만 예외가 있다. 예를 들어, 록셋(Rockset)의 경우 가져오는 데이터에 고정된 스키마나 일관된 유형을 부여하지 않고 SQL 쿼리가 가능하다.

사용자의 지리적 분포
데이터베이스 사용자가 모두 전 세계에 퍼져 있을 때 해당 지역에 추가적인 서버를 제공하지 않는 한 원격 사용자의 데이터베이스 레이턴시 한계가 설정된다. 빛의 속도 때문이다. 일부 데이터베이스는 분산형 읽기-쓰기 서버를 허용하며, 분산형 읽기 전용 서버를 제공하고 모든 쓰기는 단일 마스터 서버를 통하도록 강제하는 것들도 있다. 지리적 분포 때문에 일관성과 레이턴시도 사이의 균형이 더 어려워진다.

전 세계적으로 분산된 노드와 엄격한 일관성을 지원하는 대부분의 데이터베이스는 일반적으로 팍소스(Paxos, 램포트(Lamport), 1990년) 또는 라프트(Raft, 온가로(Ongaro) 및 오스터하우트(Ousterhout), 2013년) 알고리즘을 사용하여 일관성을 크게 훼손하지 않으면서 쓰기 속도를 높이기 위해 컨센서스 그룹을 사용한다. 

궁극적으로 일관된 분산형 NoSQL 데이터베이스는 일반적으로 비 컨센서스 P2P 중복을 사용하며, 이 때문에 2개의 복제본이 같은 레코드에 대한 동시 쓰기를 수신할 때 충돌이 발생할 수 있다. 이 충돌은 일반적으로 발견적으로(heuristically) 해결된다.

데이터 형태
SQL데이터베이스는 전통적으로 엄격한 유형의 데이터를 열과 행이 있는 사각형의 테이블에 저장한다. 이것들은 테이블들 사이에 정의된 관계에 의존하며 색인을 사용하여 선택된 쿼리의 속도를 높이고 JOINS를 사용하여 여러 테이블을 한 번에 쿼리 처리한다. 

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2019.11.13

‘질문 12개로 구성한’ 데이터베이스 선택 가이드

Martin Heller | InfoWorld

‘적절한’ 데이터베이스를 선택하는 것이 애플리케이션의 성공의 핵심이 될 수 있는 경우가 많다. 벤더의 조언을 듣거나 이미 있다는 이유로 데이터베이스를 사용하는 대신에 근본적인 데이터 저장의 목적과 요건을 고려하는 것이 좋다.

데이터베이스를 선택할 때 고려해야 할 중요한 질문은 다음과 같다.

- 애플리케이션이 성숙했을 때 얼마나 많은 데이터를 저장할 것으로 예상되는가?
- 첨두 부하(peak load)에서 동시에 몇 명의 사용자를 처리할 것으로 예상되는가?
- 애플리케이션에 필요한 가용성, 확장성, 지연 속도, 처리량, 데이터 일관성은 어느 정도인가?
- 데이터베이스 체계(schemas)는 얼마나 자주 바뀔 것인가?
- 사용자 인구의 지리적 분포는 어떠한가?
- 자연스러운 데이터의 ‘형태’는 무엇인가?
- 애플리케이션은 OLTP, OLAP 중 어떤 것을, 또는 모두를 필요로 하는가?
- 현실 속에서 기대하는 쓰기 대비 읽기의 비율은?
- 지리적 쿼리(Query) 또는 전체 텍스트 쿼리가 필요한가?
- 선호하는 프로그래밍 언어는 무엇인가?
- 예산이 있는가? 그렇다면 라이선스 및 지원 계약까지 포함시킬 수 있는가?
- 데이터 저장소에 대한 법적 한계가 있는가?

이 질문들의 의미를 살펴본다. 
 

ⓒ Image Credit : Getty Images Bank


어느 정도의 데이터를 저장할 것인가?
기가바이트 단위 이하의 수준으로 예상된다면 거의 모든 데이터베이스가 문제되지 않으며, 인-메모리 데이터베이스도 충분히 적용 가능하다. 테라바이트(Terabyte, 수천 기가바이트) 범위의 데이터베이스를 처리할 수 있는 데이터베이스 옵션도 많다.

페타바이트(Petabyte, 수백만 기가바이트) 이상의 수준이라면 사용할 수 있는 데이터베이스가 몇 개 없으며 구내 스토리지를 위한 자본 지출이나 클라우드 스토리지를 위한 운영 지출 등 상당한 데이터베이스 저장 비용에 대비해야 한다. 

이런 규모에서는 ‘라이브’ 데이터에 대한 쿼리는 속도를 위해 인-메모리나 로컬 SSD로 실행하고 전체 데이터 세트는 경제성을 위해 회전식 디스크에 보관하는 식의 단계화된 저장소 구조가 필요할 수 있다.

동시 사용자는 몇 명인가?
동시 사용자로부터 발생하는 부하를 추정하는 작업이 데이터베이스를 설치하기 직전에 서버 규모 설정 연습으로 치부되는 경우가 많다. 안타깝게도 많은 데이터베이스가 확장 문제를 가진다. 테라바이트 또는 페타바이트 단위의 데이터를 쿼리 처리하는 수천 명의 사용자를 처리할 수 없는 것이다.

동시 사용자를 예측하는 작업은 직원들이 사용하는 데이터베이스일 경우 훨씬 쉽다. 공개 데이터베이스의 경우 예상치 못하거나 계절적인 부하를 위해 여러 서버로 확장할 수 있는 옵션이 있어야 할 수 있다. 안타깝게도 대형 테이블의 수동 샤딩(sharding) 없이 수평적으로 확장할 수 있도록 지원하는 데이터베이스는 일부에 그친다. 

‘성격(-ility)’ 요건은 무엇인가?
가용성(availability), 확장성(scalability)과 같은 요건을 의미한다.  ‘성(-ility)’으로 끝나지 않는 레이턴시, 쓰루풋, 데이터 일관성(data consistency) 요건도 여기에 포함된다. 

가용성은 트랜잭션 데이터베이스의 핵심 기준인 경우가 많다. 모든 애플리케이션이 99.999%의 24/7 가용성이 필요한 것은 아니지만 그런 것들도 있다. 일부 클라우드 데이터베이스는 여러 가용성 구역에서 운영하는 한 ‘파이브 나인’(99.999%) 가용성을 제공한다. 구내 데이터베이스는 일반적으로 예약된 유지보수 기간 외에 높은 가용성에 맞추어 구성할 수 있으며, 활성-활성 서버쌍을 구성할 수 있다면 더욱 그렇다.

확장성, 특히 수평적 확장성은 역사적으로 NoSQL 데이터베이스가 SQL 데이터베이스보다 좋았다. 그러나 많은 SQL 데이터베이스가 따라잡고 있다. 동적 확장성은 클라우드에서 훨씬 쉽게 달성할 수 있다. 확장성이 좋은 데이터베이스는 부하 대비 처리량이 충분해질 때까지 확장함으로써 많은 동시 사용자를 처리할 수 있다.

레이턴시는 데이터베이스의 응답 시간과 애플리케이션의 E2E 응답 시간 모두를 의미한다. 모든 사용자 동작이 1초 미만의 응답 시간을 갖는 것이 이상적이며, 이를 위해서는 데이터베이스가 각각의 단순한 트랜잭션에 100밀리초 미만의 속도로 반응해야 하는 경우가 많다. 분석 쿼리는 수 초 또는 수 분이 소요될 수 있다. 애플리케이션은 복잡한 쿼리를 백그라운드로 수행하여 응답 시간을 아낄 수 있다.

OLTP 데이터베이스의 처리량(Throughput)은 일반적으로 초당 트랜잭션으로 측정된다. 처리량이 높은 데이터베이스는 많은 동시 사용자를 지원할 수 있다.

일반적으로 데이터 일관성은 SQL 데이터베이스에 ‘강력하다.’ 모든 읽기에서 최신 데이터가 반환된다. 데이터 일관성은 NoSQL 데이터베이스의 경우 ‘최종적’인 것부터 ‘엄격한’ 것까지 무엇이든 될 수 있다. 이벤트적 일관성(Eventual consistency)은 지연 속도를 낮추는 대신에 오래된 데이터를 읽을 위험이 있다.

한편 일관성은 오류, 네트워크 파티션, 정전 발생 시 유효성을 위해 필요한 ACID 속성 중 ‘C’에 해당된다. 4개의 ACID 속성은 Atomicity(원자성), Consistency(일관성), Isolation(고립), Durability(내구성)이다.

데이터베이스 체계는 안정적인가?
데이터베이스 체계가 시간이 지나도 크게 바뀔 가능성이 없고 대부분의 필드에서 레코드 간에 일관된 유형이 있기를 원한다면 SQL 데이터베이스가 좋은 선택일 것이다. 그렇지 않으면 (일부는 스키마를 지원조차 하지 않지만) NoSQL 데이터베이스가 애플리케이션에 더 좋을 수 있다. 하지만 예외가 있다. 예를 들어, 록셋(Rockset)의 경우 가져오는 데이터에 고정된 스키마나 일관된 유형을 부여하지 않고 SQL 쿼리가 가능하다.

사용자의 지리적 분포
데이터베이스 사용자가 모두 전 세계에 퍼져 있을 때 해당 지역에 추가적인 서버를 제공하지 않는 한 원격 사용자의 데이터베이스 레이턴시 한계가 설정된다. 빛의 속도 때문이다. 일부 데이터베이스는 분산형 읽기-쓰기 서버를 허용하며, 분산형 읽기 전용 서버를 제공하고 모든 쓰기는 단일 마스터 서버를 통하도록 강제하는 것들도 있다. 지리적 분포 때문에 일관성과 레이턴시도 사이의 균형이 더 어려워진다.

전 세계적으로 분산된 노드와 엄격한 일관성을 지원하는 대부분의 데이터베이스는 일반적으로 팍소스(Paxos, 램포트(Lamport), 1990년) 또는 라프트(Raft, 온가로(Ongaro) 및 오스터하우트(Ousterhout), 2013년) 알고리즘을 사용하여 일관성을 크게 훼손하지 않으면서 쓰기 속도를 높이기 위해 컨센서스 그룹을 사용한다. 

궁극적으로 일관된 분산형 NoSQL 데이터베이스는 일반적으로 비 컨센서스 P2P 중복을 사용하며, 이 때문에 2개의 복제본이 같은 레코드에 대한 동시 쓰기를 수신할 때 충돌이 발생할 수 있다. 이 충돌은 일반적으로 발견적으로(heuristically) 해결된다.

데이터 형태
SQL데이터베이스는 전통적으로 엄격한 유형의 데이터를 열과 행이 있는 사각형의 테이블에 저장한다. 이것들은 테이블들 사이에 정의된 관계에 의존하며 색인을 사용하여 선택된 쿼리의 속도를 높이고 JOINS를 사용하여 여러 테이블을 한 번에 쿼리 처리한다. 

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X