애플리케이션 설계자는 결국 데이터베이스 또는 서비스형 데이터베이스를 선택해야 합니다(DBaaS)를 사용하여 최신 애플리케이션 또는 마이크로 서비스를 구동할 수 있습니다. 관계형 데이터베이스 중에서 데이터베이스를 선택하는 것이 더 쉬웠습니다. 사용 사례는 크게 OLTP와 OLAP(의사 결정 지원)으로 나뉘었습니다. OLTP와 OLAP의 워크로드 차이는 잘 알려져 있었습니다. OLTP 워크로드는 다음과 같이 짧게 구성됩니다. 거래 몇 개의 무작위 행에 대해 미리 컴파일된 쿼리에 대해 밀리초 단위의 응답을 기대하는 데이터 로드, 스타/눈송이 스키마의 팩트 테이블에서 수백만 행을 스캔하는 장기 실행 쿼리로 구성된 OLAP 워크로드. 각 워크로드는 다음을 통해 성능 벤치마크와 TCO를 잘 정의, 측정 및 감사했습니다. TPC 벤치마크. 이러한 수치를 활용하여 업무량을 대략적으로 파악하고 관리와 같은 다른 측면의 요구 사항과 기능이 일치하는지 파악할 수 있습니다.
그런 다음 No-SQL 데이터베이스가 있습니다. NoSQL 데이터베이스는 운영 애플리케이션의 웹 확장 성능을 처리하기 위해 개발되었습니다. 규모를 처리하고 노드 다운(일명 파티션 허용 오차)을 견딜 수 있도록 탄력적이어야 했습니다. 이는 다양한 데이터 모델과 사용 사례에 대한 데이터베이스를 만드는 혁신을 촉발시켰습니다. JSON, 그래프, 시계열 등을 위한 데이터베이스가 있습니다. Azure 데이터베이스에서 ZODB까지, Couchbase에서 Cassandra. MongoDB에서 TiDB, 공간 데이터베이스에서 JSON 데이터베이스까지 정말 다양한 종류의 데이터베이스를 사용할 수 있습니다. 사실, NoSQL-databases.org 에는 225개의 데이터베이스와 DBaaS 2018년 11월 기준.
전자상거래 애플리케이션은 판매 보고서를 생성해야 하고, 쇼핑 카트 애플리케이션은 미결제 장바구니를 보고해야 합니다. 모든 애플리케이션은 사용자 또는 고객을 대신하여 워크플로우를 진행합니다. 이러한 작업 쿼리는 단순한 키-값 연산, 단거리 쿼리 또는 NoSQL의 복잡한 검색 쿼리일 수 있습니다. 이러한 워크로드는 대부분의 비즈니스에서 가장 중요한 부분입니다.
대용량 트랜잭션과 대용량 분석에 대한 솔루션은 겉보기에는 모순적으로 보입니다. 조회 작업이나 쿼리(예: 항공편 검색)는 매우 효율적인 조회와 애플리케이션으로의 빠른 데이터 흐름이 필요합니다. 밀리초가 중요합니다.
"그런데, 대부분의 워크로드는 혼합 워크로드입니다." - - 래리 엘리슨오라클의 창립자 겸 CTO입니다.
출처: BI 연구
혼합 워크로드를 처리해야 할 필요성을 인식한 OLTP 데이터베이스는 복잡한 쿼리(예: 해시 조인, 창 함수)를 위한 기능을 추가했고, NoSQL 데이터베이스는 SQL을 추가했습니다. SQL 데이터베이스는 JSON을 추가했습니다. 이제 우리는 선택의 역설!
범용 솔루션이 나올 때까지는 비즈니스 워크로드와 비즈니스 성과를 지원하는 솔루션을 제공하기 위해 다양한 제품과 서비스를 평가하고 조합해야 합니다. 예를 들어, OLTP에는 SQL Server를, OLAP에는 Teradata를 실행할 수 있습니다. 이커머스 애플리케이션에는 Couchbase를, 머신 러닝에는 Hadoop을 사용할 수 있습니다. 먼저 워크로드 내의 작업을 이해하기 위해 워크로드를 드릴다운해야 합니다.
그렇다면 워크로드란 무엇인가요?
기사 워크로드에 대한 정의는 무엇인가요? 는 다양한 각도에서 데이터베이스 워크로드의 예를 제공합니다. 애플리케이션 설계자는 주어진 동시성에서 애플리케이션 SLA에 따라 정의할 수 있습니다. DBA는 CPU, 메모리 사용량, I/O 처리량 등으로 워크로드를 정의할 수 있습니다. 리소스 사용량을 이해하고 이를 쿼리, 사용자, 애플리케이션과 같은 상위 엔티티에 연결하는 것이 좋습니다.
TPC-C 는 다음과 같은 방식으로 벤치마크 워크로드 및 측정에 대해 설명합니다: 가장 빈번한 거래는 평균적으로 10가지 품목으로 구성된 새 주문을 입력하는 것입니다. 각 물류창고는 회사 카탈로그에 있는 100,000개 품목의 재고를 유지하고 해당 재고로 주문을 처리하려고 노력합니다. 그러나 실제로는 한 창고에 모든 주문을 처리하는 데 필요한 모든 부품을 보유할 수 없습니다. 따라서 TPC-C는 전체 주문의 10%에 가까운 물량을 회사의 다른 창고에서 공급해야 합니다. 또 다른 빈번한 거래는 고객으로부터 받은 대금을 기록하는 것입니다. 이보다 덜 빈번하게 운영자는 이전에 접수된 주문의 상태를 요청하거나, 배송을 위해 10건의 주문을 일괄 처리하거나, 현지 물류창고의 재고 수준을 조사하여 공급 부족 가능성을 시스템에 쿼리합니다. 총 5가지 유형의 트랜잭션이 이 비즈니스 활동을 모델링하는 데 사용됩니다. TPC-C에서 보고하는 성능 지표는 분당 완전히 처리할 수 있는 주문 수를 측정하며 tpm-C로 표시됩니다.
최신 애플리케이션의 경우, 아키텍트는 모든 애플리케이션 운영, 패턴 및 해당 애플리케이션의 SLA를 이해해야 합니다. 애플리케이션 성능은 단순한 벤치마크로 측정되는 것이 아니라 장기간에 걸친 비즈니스 규모에 따른 성능으로 측정됩니다. 기간. 추가 기간 요소를 고려할 때, 느린 여름날과 사이트 방문 고객 1억 명이 좋아하는 장난감을 장바구니에 담아 구매하려고 하는 날의 인프라 규모, SLA 및 비용을 고려해야 합니다.
- 데이터베이스에 대한 애플리케이션 요청은 무엇인가요?
- 데이터 가져오기 및 설정을 위한 간단한 작업(예: 신규 고객, 신규 주문)
- 검색 요청(제품, 주문 등 검색)
- 페이지 매김 요청(날짜별로 정렬된 고객 주문 목록)
- 워크로드 보고.
- 비즈니스 인텔리전스 도구의 쿼리.
- 동시 사용자 수가 증가함에 따라 다음 중 어떤 작업을 확장해야 하나요?
- 워크로드에서 데이터베이스 노드를 추가하거나 제거할 트리거 지점은 무엇인가요?
- 장애 조치 전략은 무엇인가요?
NoSQL 데이터베이스 비교:
관계형 데이터베이스(일명 SQL 데이터베이스)는 동일한 관계형 모델, 거의 동일한 데이터 유형, 유사한 SQL을 구현했습니다. 차이점은 TPC 벤치마크로 측정할 수 있는 성능과 보다 주관적인 관리 용이성에 있었습니다.
No-SQL 데이터베이스는 다양성이야말로 게임의 이름입니다. 키-값, JSON, 와이드 컬럼, 그래프, 시계열 및 공간 등을 위한 전문 데이터베이스가 있습니다. 이들은 서로 다른 데이터 모델과 이 모델에서 효과적으로 수행할 수 있는 다양한 작업을 나타냅니다. 각각 고유한 API, 쿼리 언어, 성능 특성, 확장 기능이 있습니다.
이전에 앱에서 사용자의 대기 중인 주문을 표시했다면 새 데이터베이스에서도 여전히 그렇게 해야 합니다. 동일한 결과를 얻는 방법은 변경할 수 있지만 결과 자체는 변경할 수 없습니다. 다시 워크로드로 돌아옵니다. 전체 애플리케이션 워크로드와 애플리케이션이 생성하는 데이터베이스 워크로드를 이해해야 합니다. 그런 다음 성능, 확장 측정 및 확장을 수행하세요. 간단한 사용 사례입니다, YCSB 벤치마크가 도움이 되겠지만 복잡한 사용 사례에는 도움이 되지 않습니다, YCSB-JSON 를 사용할 수 있습니다. 이 연습에서는 워크로드를 각각의 데이터베이스 작업으로 변환하여 측정해야 합니다. 탄력성, 복제 속도, 장애 조치와 같은 시스템 특성뿐만 아니라 각 중요 작업에 대해 측정하세요.
워크로드에 대한 데이터베이스를 평가하면서 중요한 교훈을 얻을 수 있습니다:
새로운 종류의 데이터베이스를 사용할 수 있다고 해서 데이터베이스에 대한 비즈니스 및 애플리케이션 요구 사항이 변경되는 것은 아닙니다.
요약하자면, 워크로드는 수정된 핑크 플로이드 가사. (로저 워터스에게 사과드립니다).
데이터베이스 워크로드
캐시하는 모든 것
그리고 플러시하는 모든 것
공유한 모든 것
모든 해시
확장하는 모든 것
실패한 모든 것
테스트하는 모든 것
저장하는 모든 것
공유하는 모든 것
그리고 저장하는 모든 것
그리고 거래하는 모든 것
시작, 커밋 또는 롤백
생성하는 모든 것
그리고 당신이 하는 모든 일
그리고 취소하는 모든 것
그리고 다시 실행하는 모든 것
삭제한 모든 항목
그리고 추가하는 모든 노드(추가하는 모든 노드)
그리고 검색하는 모든 것
그리고 인덱싱하는 모든 키
그리고 모든 것이 계획되어 있습니다.
그리고 모든 것이 실행됩니다.
그리고 이 모든 것이 바뀝니다.
그리고 (데이터) 기반 아래의 모든 것이 조율됩니다.
하지만 기반은 클라우드에서 실행됩니다.
