데이터ㆍ분석

"성급하면 결국 골칫거리 된다" 데이터베이스 선택 팁 5가지

Jordan Tigani | InfoWorld 2022.03.22
데이터베이스 선택은 먼 미래의 애플리케이션과 개발에까지 큰 영향을 미친다. 그런데도 개발자의 데이터베이스 선택은 감정적으로 흐르는 경향이 있고, 오로지 지금의 애플리케이션 요구사항만을 기준으로 데이터베이스를 고르는 경우가 많다. 
 
ⓒ Getty Images Bank

예를 들어 어떤 데이터베이스에 대한 느낌이 좋다는 이유로 개발자는 단순히 직감을 따르곤 한다. 데이터베이스가 현재와 미래의 애플리케이션에 맞게 효과적으로 작동할지에 대한 분석은 생략한다. 선택할 수 있는 데이터베이스가 너무 많아 비교할 엄두를 내지 못하는 때도 있다. 이럴 때는 사고가 마비되고 결국 현재의 애플리케이션에 필요한 요소를 충족하는 데이터베이스를 선택하게 된다. 

문제는 미래의 모든 애플리케이션 요구사항을 미리 알 수 없다는 것이다. 보통 애플리케이션은 처음에는 단순하게 시작했다가 시간이 지날수록 복잡해지기 마련이다.

실제로 많은 개발자가 포스트그레SQL로 시작한다. 반구조적 데이터를 다뤄야 하고 유연한 스키마가 필요해지면 몽고DB를 추가한다. 그런 다음 로그 검색이나 패싯 검색을 하기 위해 일래스틱서치(Elasticsearch)로 눈을 돌린다. 하지만 속도가 매우 빠르지 않다는 것을 발견하고, 레디스(Redis)를 캐시로 덧붙인다. 분석을 해야 할 때가 오면 스노우플레이크(Snowflake)와 같은 데이터 웨어하우스를 불러들인다. 결국 모든 상황이 이내 혼란스럽게 된다. 데이터베이스 난립으로 데이터베이스 간의 데이터 이동과 값비싼 ETL(추출, 변환, 로드) 프로세스가 개발자의 걱정거리가 된다. 

이처럼 많은 개발자가 종종 실패의 길로 걸어가지만 필요한 모든 것을 얻을 수 있는 다른 방법도 있다. 모든 요구사항을 충족하는 데이터베이스를 선택하는 방법을 알아보자. 
 

한 치 앞이 아니라 먼 미래를 보라

데이터베이스 마이그레이션과 플랫폼 변경은 간단한 일이 아니다. 데이터베이스를 한 번 선택하면 되돌리기 어렵고 한 아키텍처에 종속될 수 있음을 항상 의식해야 한다. 선택한 데이터베이스가 현재의 요구사항뿐만 아니라 미래의 애플리케이션 요구사항에도 부합할지 다음과 같은 질문을 해본다. 
 
  • 애플리케이션의 사용량이 급증하면 데이터베이스에서 무엇이 필요한가? 
  • 선택한 데이터베이스가 나중에 새로운 기능을 추가할 방법을 제공하는가? 
  • 지금 데모를 보여줄 수 있는지만을 기준으로 데이터베이스를 선택하고 있지는 않은가? 

이런 고민을 하다 보면 '그냥 몽고DB로 하고 신경 끄자'는 생각 쪽으로 기울 수도 있다. 하지만 오늘의 성급한 결정이 미래의 두통을 일으킬 수 있음을 상기하라.
 

스케일 아웃의 단점도 명확히 파악하라

전통적인 데이터베이스는 스케일 업 아키텍처를 기반으로 했다. 즉, 속도를 높이려면 더 강력한 하드웨어를 구매해 기존 하드웨어를 대체해야 했고, 당연히 상당한 부가 비용이 발생했다. 반면 오늘날 데이터베이스는 보통 스케일 아웃 아키텍처를 기반으로 한다. 하드웨어를 추가해야 한다는 점은 같지만, 비용과 성능 향상이 비례 관계에 있으므로 구매 관점에서는 훨씬 더 유리하다.

마이SQL, 포스트그레SQL과 같은 오래된 데이터베이스는 이런 스케일 아웃 아키텍처의 이점을 인식하고 수평 확장 기능을 추가했다. 여기에 사용된 일반적인 방법의 하나는 샤딩, 즉 데이터베이스를 개별 조각(샤드)으로 나누는 것이다. 하나의 거대한 마이SQL 인스턴스 대신 10개의 작은 마이SQL 인스턴스를 사용하는 것이다. 

이 방식의 스케일 아웃을 지원하는 데이터베이스 업체를 선택할 때 주의할 부분은, 여러 샤드 간에 데이터를 공유해야 하는 쿼리를 실행할 때 문제가 발생할 수 있다는 점이다. 특히 한 지역의 주요 고객, 또는 가장 활발한 사용자를 찾는 것과 같은 분석 스타일의 쿼리는 이 아키텍처에서 문제가 될 수 있다. 
 

핫/콜드 데이터를 동시에 처리하라

열 스토리지는 대량의 데이터를 빠르게 스캔할 수 있어 분석 작업에 이상적이다. 반면 행 스토리지는 저지연 조회와 업데이트가 필요한 트랜잭션 워크로드에 잘 맞는다. 과거에는 데이터베이스를 선택할 때 열 기반과 행 기반 스토리지 중 하나를 선택해야 했다.

그러나 이제는 이런 어려운 선택을 할 필요가 없다. 행 스토리지와 열 스토리지를 같은 테이블로 결합하는 데이터베이스가 있기 때문이다. 이런 데이터베이스에서는 데이터가 메모리 내 행 스토리지에 작성되므로 매우 빠른 트랜잭션과 조회가 가능하다. 잘 쓰이지 않는 ‘콜드’ 데이터는 열 스토리지로 다시 옮겨지므로, 효율적인 분석도 할 수 있다.
 

전통적 디스크를 피하라

전통적인 데이터베이스에서 지연이 발생한 가장 큰 원인이 바로 자기 디스크였다. 데이터베이스 업체는 이 지연을 최소화하는 알고리즘을 만들었지만, 디스크가 회전하고 헤드가 원하는 위치로 이동하는 방식에서는 지연 시간을 줄이는 데 물리적인 한계가 있다. 

이런 I/O 지연 문제는 기계적 구동부가 없는 SSD를 도입해 줄일 수 있다. SSD는 회전 디스크보다 최대 200배 더 빠르다. 더 많은 용량이 필요하면 SSD를 추가하기만 하면 된다. 트랜잭션 로그에 쓰기, 즉 트랜잭션 로그에 덧붙이기로 지속성을 확보할 수 있다. 읽기 또는 조회 쿼리만 한다면 디스크를 건드릴 필요조차 없다. 
 

'적을수록 좋다' 원칙을 이해하라

과거의 데이터베이스는 속도와 유연성, 애플리케이션 지원 기능이 부족하다. 많은 기업이 오랜 기간에 걸쳐 그처럼 다양한 데이터베이스를 도입해 운영해 온 이유다. 기본적으로 데이터 사용량이 많은 애플리케이션에는 새로운 종류의 데이터베이스가 필요했다.

하지만 데이터베이스 종류는 적을수록 좋다. 이제는 효율적으로 확장할 수 있고 아키텍처를 비약적으로 간소화할 수 있는 단일 데이터베이스를 찾아야 한다. 트랜잭션 워크로드와 분석 워크로드를 모두 처리하도록 설계된 데이터베이스, 대용량의 동적인 데이터 집합을 대상으로 높은 동시성으로 빠른 분석 쿼리를 수행하는 데이터베이스를 찾고, 모든 데이터 형식에 대처하는 멀티 모델 데이터베이스를 도입하는 것이 좋다.
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.