데이터베이스를 선택할 때 5가지 요소

다음은 데이터베이스가 프로젝트에 적합한 시기를 결정하는 방법입니다.

최근 사용 사례에 대한 데이터베이스를 선택할 때(또는 현재 필요에 맞지 않는 데이터베이스를 교체할 때) 좋은 소식은 선택할 수 있는 옵션이 많다는 것입니다.

이전보다 훨씬 더 많은 데이터베이스를 고려하고 비교해야 합니다. 2012년 12월, DB-Engines.com이 처음으로 데이터베이스 순위를 매기기 시작한 첫 해 말에는 73개의 시스템 목록이 있었습니다(처음 시작한 18개 시스템 목록에서 크게 증가). 2022년 12월 현재, 400개의 시스템에 불과합니다. 이는 지난 10년 동안 데이터베이스 기술이 캄브리아기에서 폭발적으로 증가했음을 나타냅니다. 탐색할 수 있는 옵션은 매우 다양합니다: SQL, NoSQL 및 SQL과 NoSQL의 혼합 또는 NoSQL의 여러 데이터 모델(문서, 키 값, 와이드 열, 그래프 등의 두 가지 이상의 옵션 결합)이 될 수 있는 "멀티 모델" 데이터베이스의 혼합이 있습니다.

또한 사용자는 완전한 인기와 사용 사례에 대한 적합성을 혼동해서는 안 됩니다. 네트워크 효과는 확실히 장점이 있지만 그룹 사고, 혁신 및 경쟁으로 이어질 수도 있습니다.  

최근에 사용자들이 데이터베이스를 요약하고 비교할 때 가장 중요하게 생각해야 하는 다섯 가지 요소에 대해 알아보겠습니다.

 

 

데이터베이스를 선택할 때 5가지 요소

 

 

다섯 가지 요인

소프트웨어 아키텍처 - 데이터베이스가 가장 효율적인 데이터 구조, 유연한 데이터 모델 및 풍부한 쿼리 언어를 사용하여 워크로드 및 쿼리 패턴을 지원합니까?

하드웨어 활용도 - 최신 하드웨어 플랫폼을 최대한 활용할 수 있습니까? 아니면 CPU 사이클의 상당량을 충분히 활용하지 못하는 상태로 남겨둘 것입니까?

상호 운용성 - 개발 환경에 얼마나 쉽게 통합할 수 있습니까? 프로그래밍 언어, 프레임워크 및 프로젝트를 지원합니까? 마이크로서비스 및 이벤트 스트리밍 아키텍처에 통합되도록 설계되었습니까?

RASP — 안정성, 가용성, 확장성, 서비스 가능성 및 물론 성능에 필요한 품질이 있습니까?

배포 - 이 데이터베이스는 사내와 같은 제한된 환경에서만 작동합니까, 아니면 단일 데이터 센터 또는 단일 클라우드 공급업체에서만 작동합니까? 아니면 전 세계 어디에 어떻게 배치해야 할까요?

 

이러한 분석은 주관적입니다. 4개의 요인, 12개, 20개 또는 100개의 기준 리스트가 있을 수 있습니다. 물론 소프트웨어 아키텍처와 같은 각 요소는 "스토리지 엔진", "분산 처리 아키텍처", 심지어 "쿼리 언어"와 같은 하위 범주로 나뉩니다. 하지만 이것이 일반적인 범주로 분류하는 방법입니다.

 

 

소프트웨어 아키텍처

여기서 중요한 고려 사항은 "데이터베이스가 가장 효율적인 데이터 구조, 유연한 데이터 모델 및 풍부한 쿼리 언어를 사용하여 특정 워크로드 및 쿼리 패턴을 지원합니까?"입니다

워크로드 - 쓰기 작업량이 많은 트랜잭션 워크로드를 수행해야 합니까, 아니면 읽기/쓰기 작업이 혼합되어야 합니까? 아니면 주로 읽히는 분석 워크로드를 수행할 것입니까? 트랜잭션과 분석이 혼합된 하이브리드 워크로드가 필요합니까? 이 워크로드는 실시간입니까, 배치된 워크로드입니까, 아니면 혼합 워크로드입니까? 초당 지속적인 이벤트 흐름인가요, 아니면 매끄럽고 규칙적인 하루 동안 예측 가능한 상승과 하락이 있나요? 아니면 갑작스런 트래픽 폭발로 인한 확률적 충격에 대처할 계획을 세울 필요가 있습니까?

데이터 모델 — 키-값 쌍을 다루고 있습니까? 넓은 열 저장소(행 기반의 "키-키-값" 데이터)는 무엇입니까? 열 저장소(열 데이터)입니까? 문서요? 그래프? RDBMS(테이블 및 JOIN 포함)? 아니면 완전히 다른 것일 수도 있어요. 완전히 정규화된 데이터를 처리할 시간과 필요가 있습니까? 아니면 너무 많은 비정형 데이터를 너무 빨리 흡수하여 정규화가 헛수고가 될 것 같습니까? 우선 비정형화된 데이터 모델을 사용하는 것이 좋겠습니까? 여기에는 단 하나의 "옳은" 대답은 없습니다. "상황에 따라 다르다"는 것을 받아들여야 합니다.

언어 쿼리 — 여기에는 분명 편견이 더 많습니다. 데이터 엔지니어링 팀은 백엔드 쿼리 모델을 숨기거나 숨길 수 있지만 대부분의 사용자는 자신만의 편견과 선호도를 가지고 있기 때문입니다. 이것이 SQL이 이러한 잠금 상태를 유지하는 주요 이유 중 하나입니다. 동시에 사용할 수 있는 새로운 쿼리 언어도 있습니다. 카산드라 및 실라DB에서 사용하는 CQL(Cassandra Query Language)과 같은 일부는 SQL과 유사합니다. SQL 사용자에게 친숙합니다. 하지만 속지 마십시오. 테이블 조인이 없습니다! 그런 다음 JSON과 같은 일련의 새로운 학교 질의 언어가 사용될 수 있습니다. 이것이 Amazon DynamoDB 쿼리의 작동 방식입니다. 여기서도 실라DB는 DynamoDB와 호환되는 Alternator 인터페이스를 사용하는 JSON 쿼리 모델을 지원합니다. 어느 쪽으로 기울어지든, 쿼리 언어는 고려에서 후발적이어서는 안 됩니다.

트랜잭션/운영/CAP — 어느 것이 더 중요합니까? ACID 트랜잭션이 완전히 일치합니까? 또는 성능이 뛰어나고 가용성이 높은 기본 CRUD 작업을 수행할 수 있습니까? CAP 정리에 따르면 일관성, 가용성 또는 파티션 공차의 세 가지 중 두 가지를 가질 수 있습니다. 분산 데이터베이스는 항상 파티션을 허용해야 하기 때문에 소위 "CP" 모드 일관성 지향 시스템 또는 "AP" 모드 가용성 지향 시스템 중에서 선택할 수 있습니다. 이러한 모드에서는 구현 세부사항을 고려해야 합니다. 예를 들어, 분산 시스템 내에서 강력한 일관성을 달성하는 방법은 크게 다를 수 있습니다. Paxos, Raft, ZAB(Zookeeper) 등과 같이 선형화 가능성을 보장하기 위해 다양한 합의 알고리듬을 선택하는 것도 고려하십시오. 서로 다른 알고리즘 외에도 각 구현은 다른 알고리즘에 따라 크게 다를 수 있습니다.

데이터 배포 — "분산 시스템"이라고 하면 정확히 무엇을 의미합니까? 로컬 단일 데이터 센터 클러스터를 말씀하시는 건가요? 아니면 다중 데이터 센터 클러스터링을 말하는 것입니까? 클러스터 간 업데이트는 어떻게 이루어집니까? 하나의 논리적 클러스터로 모두 간주됩니까? 아니면 클러스터 간 동기화가 필요합니까? 데이터 현지화 및 GDPR 컴플라이언스를 어떻게 처리합니까?

 

 

하드웨어 사용률

소프트웨어의 경계를 계속 확장하는 기본 하드웨어의 혁명을 진행 중입니다. 많은 소프트웨어 애플리케이션, 특히 많은 데이터베이스는 여전히 수십 년 된 기원, 설계 및 가정에 뿌리를 두고 있습니다.

CPU 사용률/효율성 — CPU 사용률이 40% 또는 50%를 초과하면 많은 소프트웨어가 제대로 실행되지 않는다고 합니다. 즉, 해당 소프트웨어를 비효율적으로 실행해야 하므로 박스의 절반이 정기적으로 충분히 활용되지 않습니다. 실제로는 실제 필요한 것보다 두 배 이상의 인프라 비용을 지불해야 합니다. 따라서 시스템이 분산 처리를 처리하는 방식을 살펴봐야 합니다.

RAM 사용률/효율성 — 데이터베이스가 일관되게 메모리에 바인딩되어 있습니까? 캐슁이 너무 공격적입니까, 아니면 너무 비대합니까(예: 여러 계층의 캐슁), 불필요한 데이터를 메모리에 보관하고 있습니까? 읽기 및 쓰기 경로를 어떻게 최적화합니까?

스토리지 활용률/효율성 - 데이터베이스에서 사용하는 스토리지 형식은 무엇입니까? 무거운 파일 잠금 메커니즘이 필요할 수 있는 소형 가변 테이블이 있습니까? 또는 빠른 쓰기를 생성할 수 있지만 공간 및 읽기 증폭 비용이 드는 불변 테이블을 사용합니까? 계층형 스토리지를 사용할 수 있습니까? 동시성을 어떻게 처리하나요? 파일이 행 단위로 저장됩니까(트랜잭션 사용 사례에 적합), 열 단위로 저장됩니까(반복성이 높은 데이터에 대한 분석에 적합)? "올바른" 대답이 하나만 있는 것은 아니라는 점에 유의하십시오. 각 솔루션은 서로 다른 사용 사례에 맞게 최적화됩니다.

네트워크 활용률/효율성 — 여기서는 클라이언트-서버 클러스터 통신과 클러스터 내 통신의 효율성에 대해 모두 고려해야 합니다. 클라이언트/서버 모델은 동시성, 연결 풀링 등을 통해 보다 효율적으로 만들 수 있습니다. 클러스터 내 통신은 일반적인 운영/트랜잭션 채팅(업데이트 또는 쓰기로 데이터 복제)뿐만 아니라 토폴로지 변경 중 노드 간 데이터 스트리밍 및 밸런싱과 같은 관리 작업에 이르기까지 다양합니다.

 

 

상호 운용성

데이터베이스가 섬이 아닙니다. 귀사의 개발 환경에 얼마나 쉽게 통합할 수 있습니까? 프로그래밍 언어, 프레임워크 및 프로젝트를 지원합니까? 마이크로서비스 및 이벤트 스트리밍 아키텍처에 통합되도록 설계되었습니까?

프로그래밍 언어/프레임워크 — "우리는 X 상점입니다"라는 소리가 계속 들립니다. 여기서 X는 선호하는 프로그래밍 언어 또는 프레임워크를 나타냅니다. 데이터베이스에 해당 언어로 통합하는 데 필요한 클라이언트, SDK, 라이브러리, ORM 및/또는 기타 패키지가 없는 경우 데이터베이스가 존재하지 않을 수 있습니다. 공정하게 말하자면, 데이터베이스의 대규모 폭발은 프로그래밍 언어의 대규모 폭발과 동시에 발생합니다. 그러나 클라이언트를 위한 프로그래밍 언어 지원을 검토하는 것은 가치가 있습니다. 이는 데이터베이스 자체가 작성될 수 있는 언어(소프트웨어 아키텍처 및 효율성에 영향을 미칠 수 있음)와는 다릅니다. 이것은 순전히 해당 백엔드 데이터베이스에 연결하기 위해 앱을 작성할 수 있는 언어에 관한 것입니다.

이벤트 스트리밍 / 메시지 큐 — 데이터베이스는 단일 정보원일 수 있지만 회사에서 실행 중인 유일한 시스템은 아닙니다. 실제로, 회사의 전체 데이터 및 정보 공간에서 서로 다른 조각을 처리, 분석 및 공유하는 서로 다른 데이터베이스가 있을 수 있습니다. 이벤트 스트리밍은 현대 기업에서 데이터 사일로를 방지하기 위해 점점 더 보편화되고 있는 미디어이며, 오늘날 데이터베이스는 실시간 이벤트 스트리밍 및 메시지 큐 기술과의 통합만큼 우수합니다. 데이터베이스가 싱크와 데이터 소스 역할을 모두 수행할 수 있습니까? CDC(Change Data Capture)가 있습니까? Apache Kafka, Apache Pulsar, RabbitMQ와 같은 즐겨찾는 이벤트 스트리밍 및 메시지 큐 기술에 연결됩니까?

API - 애플리케이션 및 마이크로서비스 아키텍처로의 데이터베이스 통합을 용이하게 하기 위해 데이터베이스가 RESTful 인터페이스 또는 GraphQL과 같은 하나 이상의 API를 지원합니까? GUI 인터페이스를 통해 모든 작업을 수행하는 대신 프로그래밍 방식으로 프로비저닝할 수 있는 관리 API가 있습니까? 처음에는 배포 시스템을 관리하고 자동화할 때까지 GUI를 사용하는 것이 편리해 보일 수 있습니다.

기타 통합 — CI/CD 툴체인은 어떻습니까? 관찰 가능한 플랫폼이요? 데이터베이스를 플러그형 스토리지 엔진 또는 광범위한 아키텍처의 기본 요소로 사용하는 것은 어떻습니까? 인프라의 역할을 얼마나 잘 수행합니까, 아니면 이미 사용 중인 인프라에 얼마나 적합합니까?

 

 

RASP

이 약어는 수십 년 전으로 거슬러 올라가며 일반적으로 하드웨어 환경에서 사용됩니다. 안정성, 가용성, 서비스 가능성(또는 확장성) 및 성능을 나타냅니다. 기본적으로 이러한 "-ility"는 시스템을 쉽게 실행할 수 있는 "설비"입니다. 데이터베이스에서는 시스템을 유지하고 안정적으로 유지하기 위해 얼마나 많은 수동 개입과 "플레이트 회전"을 수행해야 하는지 고려해야 합니다. 일반적인 작동 조건에서 데이터베이스가 스스로 처리할 수 있는 정도를 나타내며, 장애 상태를 최대한 완화할 수도 있습니다. 일반적인 플랫폼 엔지니어는 많은 새로운 노드를 회전시킵니다.

신뢰성 — 이 제품이 무너지거나 데이터가 사라지는 것을 방지하려면 얼마나 많은 수리 작업을 해야 합니까? 데이터베이스는 내구성이 좋습니까? 얼마나 살아남을 수 있을까요? 클러스터를 다시 동기화하기 위해 어떤 엔트로피 방지 메커니즘이 포함되어 있습니까? 백업 시스템의 성능은 어느 정도입니까? 더 중요한 것은 복원 시스템이 얼마나 우수하다는 것입니까? 그리고 한 번의 "이런!"로 개인들이 물건을 떨어뜨리지 않도록 보호하기 위한 작전용 가드레일이 있나요

가용성 — 단기 네트워크 파티션 및 일시적 노드를 사용할 수 없는 경우 데이터베이스에서 수행하는 작업은 무엇입니까? 노드가 완전히 실패하면 어떻게 됩니까? 네트워크 장애가 몇 시간 이상 지속되면 어떻게 될까요?

서비스 가능성 — 오늘날 일반적인 유행어는 "관찰 가능성"으로, 일반적으로 로깅, 추적 및 메트릭의 세 가지 축을 포함합니다. 물론, 데이터베이스에 관찰 가능성이 내장되어 있어야 합니다. 그러나 서비스 가능성은 그 이상입니다. 다운타임 없이 업그레이드를 얼마나 쉽게 수행할 수 있습니까? 유지보수 작업에 얼마나 문제가 없습니까?

확장성 — 일부 데이터베이스는 시작하기에 좋습니다. 그런 다음 벽에 부딪힙니다. 하드. 확장성을 통해 관리 중인 총 데이터, 초당 총 작업 수 또는 지리적 한계(예: 단일 데이터 센터를 넘어 진정한 글로벌 구현 가능성)에 대해 걱정할 필요가 없습니다. 또한 수평적 확장성(클러스터에 노드를 추가하는 것에서 확장 가능)과 수직적 확장성(Vertical scalability)을 통해 CPU 수, RAM 수, 스토리지 수가 계속 증가하는 서버에 데이터베이스를 배치할 수 있습니다.

성능 — 결론적으로 데이터베이스가 지연 시간이나 처리량 SLA를 충족하지 못하면 운영 환경에서 원활하게 운영할 수 없습니다. 또한 확장성과 관련하여 많은 데이터베이스가 소규모로 또는 테스트 데이터를 사용하는 정적 벤치마크를 기반으로 성능 요구사항을 충족하는 것처럼 보이지만 실제 운영 워크로드를 사용할 경우 증가하는 쿼리의 빈도, 가변성 및 복잡성을 따라잡지 못합니다. 따라서 성능에는 선형 척도와의 강력한 상관 관계가 필요합니다.

 

 

배포

그런 다음 위의 모든 것을 필요한 곳에서 실행해야 합니다. 이 데이터베이스는 사내와 같은 제한된 환경에서만 작동합니까, 아니면 단일 데이터 센터 또는 단일 클라우드 공급업체에서만 작동합니까? 아니면 전 세계 어디에 어떻게 배치해야 할까요? 

잠금 — 사내에서 실행할 수 있습니까? 아니면 반대로 사내 구축에만 국한됩니까? 특정 퍼블릭 클라우드 공급업체에만 국한됩니까, 아니면 선택한 클라우드 공급업체에서 실행할 수 있습니까? 하이브리드 클라우드 또는 멀티클라우드 구축 옵션은 무엇입니까?

관리/제어 — 마찬가지로, 이 데이터베이스는 자체 관리형 데이터베이스로만 사용할 수 있습니까, 아니면 완전 관리형 서비스형 데이터베이스(DBA)로 사용할 수 있습니까? 전자는 팀이 시스템을 완전히 제어할 수 있도록 하고, 후자는 팀의 관리 부담을 덜어줍니다. 둘 다 트레이드오프가 있어요. 하나만 선택할 수 있습니까, 아니면 데이터베이스에서 사용자가 이 두 가지 비즈니스 모델 간에 전환할 수 있습니까?

자동화 및 오케스트레이션 — 운영 환경에서 이를 지원할 Kubernetes 운영자가 있습니까? 테라포름과 앤서블 스크립트요? 이 항목이 목록의 마지막 항목이지만, 생산을 고려할 때 나중에 고려해야 할 사항은 아닙니다.