높은 동시 저장 시스템


12

요구 사항에 3 개의 거대한 테이블 (구조화 된 데이터)이 있고 각각에 300 억 개의 행 (총 4TB 크기)이 있고 많은 동시 사용자 (원격 LAN 시스템의 병렬 OS 스레드)가 SELELCT WHERE GROUPBY 쿼리를 통한 데이터 및 동시 동시 (예 : 10,000 개의 동시 읽기) 및 사용자는 2000 개의 동시 작성기 (데이터 센터 LAN 네트워크 전체)와 매우 동시 적으로이 테이블에 데이터를 삽입 (업데이트하지 않아야 함)해야합니다. . 사용자는 각 읽기 및 쓰기가 발생하는이 저장소에서 가능한 한 빨리 읽고 삽입하여 ms ~ 1 초 범위를 원할 것입니다.

이러한 요구 사항을 충족시키기 위해 어떤 기술을 권장합니까? 이를 수행 할 수있는 데이터 저장소 또는 키 값 저장소가 있습니까? 클라우드는 옵션이 아닙니다.

일부 설명 :

사용자는 즉시 데이터를 볼 필요가 없으며 최종 일관성이 허용됩니다. 데이터는 스토리지가 제공 할 수있는 드라이버를 통해 액세스하며 사용자는 데이터 센터의 원격 시스템에서 실행중인 스레드 일뿐입니다. 쿼리는 주로 SELECT WHERE GROUPBY와 비슷합니다.

데이터는 테이블 형식이며 각 행은 약 60 바이트입니다.

DynamoDB 또는 유사한 솔루션을 사용할 수없는 클라우드 옵션이 없습니다. 데이터 센터에서 내부적으로 호스팅 할 수 있어야합니다.

테이블의 모든 데이터를 항상 읽을 수 있으며 사용 패턴을 예측할 수 없습니다. 조인 또는 초장 쿼리가 없습니다. DR은 필요하지 않지만 합리적인 HA가 필요하지만 화려한 것은 아닙니다. 모든 독자는 where 절과 행이 실제로 관련되지 않은 행을 기반으로 배치를 가져옵니다. 각 행마다 고정 길이를 가질 수는 있지만 스토리지 계층이 걱정할 것으로 기대합니다.

또한, 가장 큰 관심사는 동시 읽기로 발생하는 모든 동시 쓰기입니다.

이에 대한 귀하의 통찰력은 높이 평가됩니다.

그리고 더 많은 것은 다른 객체 유형을 보유하는 각 300 억 개의 행이있는 3 개의 테이블이 있습니다.


대부분의 사람들, 즉 일반 대중의 99 %와 마케팅 사람들의 100 %가 클라우드라고 부르는 것은 다른 사람이 유지 하는 클러스터 일 뿐이므로 클라우드를 정의 하십시오 .

즉, Amazon 또는 Azure와 같은 퍼블릭 클라우드에서만 사용할 수있는 DynamoDB 또는 일부 기술을 사용할 수 없습니다.
iCode

답변:


6

최종 일관성이 허용되고 모든 쿼리가 집계 된 경우 지연 시간이 짧은 OLAP 시스템이 적합 할 수 있습니다. 요구 사항은 알고리즘 거래 플랫폼과 비슷합니다. 이 유형의 아키텍처는 최신 데이터에 대한 집계 통계 분석 계산을 수행해야하는 거래 현장 시스템에서 종종 사용됩니다.

날짜별로 데이터를 분할 할 수 있고 이전 행이 업데이트되지 않으면 일반 RDBMS 플랫폼이 지원하는 Microsoft Analysis 서비스와 같은 기존 OLAP 서버를 사용하여 하이브리드 OLAP 시스템을 구축 할 수 있습니다. 최대 4TB의 데이터를 처리 할 수 ​​있어야하며 SQL Server와 SSAS는 모두 공유 디스크 클러스터를 수행합니다. 다른 공급 업체에서도 유사한 OLAP 시스템 (예 : Oracle / Hyperion Essbase)을 사용할 수 있습니다.

OLAP 서버는 집계와 함께 기본 저장소에 데이터를 유지함으로써 작동합니다. 대부분은 분할 된 데이터를 지원합니다. 또한 대부분은 ROLAP 모드에서 작동하며 기본 데이터베이스에 대해 쿼리를 실행합니다. 기억해야 할 중요한 점은 스토리지 전략을 파티션별로 관리 할 수 ​​있으며 파티션을 프로그래밍 방식으로 다른 파티션으로 전환 할 수 있다는 것입니다.

이 모델에서 히스토리 데이터는 데이터 집계와 함께 MOLAP 파티션에 저장됩니다. 집계에서 쿼리를 충족 할 수 있으면 서버가이를 사용합니다. 집계는 쿼리에 맞게 조정될 수 있으며 올바른 집계는 쿼리를 해결하는 데 필요한 계산량을 크게 줄입니다. 이 유형의 시스템에서는 매우 응답 성이 뛰어난 집계 쿼리가 가능합니다.

필요한 경우 현재 월, 일 또는 심지어 한 시간 동안 작은 선행 파티션을 유지함으로써 실시간 데이터를 구현할 수 있습니다. OLAP 서버는 데이터베이스에 대해 쿼리를 발행합니다. 이 파티션이 충분히 작 으면 DBMS가 빠르게 응답 할 수 있습니다. 정기적 인 프로세스는 새로운 선행 파티션을 작성하고 닫힌 히스토리 기간을 MOLAP로 변환합니다. 이전 파티션을 병합하여 기록 데이터를 원하는 그레인으로 관리 할 수 ​​있습니다.

데이터베이스에 쓰는 클라이언트는 기본 RDBMS를 바로 작성합니다. 히스토리 데이터가 정적으로 유지되면 선행 파티션에만 기록됩니다. 4TB는 추가 DBMS 성능이 필요한 경우 SSD를 사용하기위한 실용적인 볼륨입니다. 주류 공급 업체도 더 빠른 SLC 장치를 옵션으로 갖춘 SSD 기반 제품을 제공합니다.


당신의 응답을 주셔서 감사합니다. 당신이 올바른지. 내 문제는 알고리즘 거래 플랫폼과 비슷하지만 다릅니다. RDBMS 경로를 시도했지만 확장 할 수 없었습니다. 데이터 크기가 커짐에 따라 확장이 가능하고 OLAP 시스템의 복잡성이없는 스토리지가 필요합니다. 3 개의 테이블에서 더 많은 TB에 도달하면 RDBMS는 많은 잠금 및 유사한 문제를 발생시킵니다. nosql 옵션이 이러한 요구 사항을 충족시킬 수 있기를 바랍니다. 그것에 대한 생각?
iCode

@MDotnet 12k 동시 사용자, 4TB 크기의 문제에 대한 간단한 솔루션에 대한 기대 / 요건은 비현실적 일 수 있습니다. RDBMS 접근 방식을 살펴본 결과 확장되지 않았다고 언급했습니다. 1) Q에이 세부 사항을 추가 할 수 있습니까? 2)이 답변은 순수한 관계형 데이터베이스가 아닌 하이브리드 ROLAP / MOLAP 방식을 옹호합니다.
Mark Storey-Smith

저는 DBA가 아니며 "공개에 의한 드라이브"는 대부분의 전문 사이트에 좋지 않다고 생각합니다. +1
psr
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.