Google Cloud Spanner: 좋음, 나쁨, 나쁨

안녕하세요, 하브로프스크 주민 여러분. 늘 그렇듯, 우리는 새로운 강좌 시작에 앞서 흥미로운 자료를 계속해서 공유하고 있습니다. 오늘은 특히 여러분을 위해 과정 개설에 맞춰 Google Cloud Spanner에 대한 기사를 게시했습니다. "개발자를 위한 AWS".

원래 출판된 시기 광속 본부 블로그.

전 세계 소매업체, 레스토랑 경영자, 온라인 판매자에게 다양한 클라우드 기반 POS 솔루션을 제공하는 회사인 Lightspeed는 다양한 거래, 분석 및 검색 사용 사례에 대해 여러 유형의 데이터베이스 플랫폼을 사용합니다. 이러한 데이터베이스 플랫폼은 각각 장단점이 있습니다. 따라서 Google이 사실상 무제한의 수평 확장성과 99,999% SLA(서비스 수준 계약) 등 관계형 데이터베이스 세계에서는 볼 수 없는 유망한 기능인 Cloud Spanner를 시장에 출시했을 때, — 우리는 그것을 손에 넣을 기회를 놓칠 수 없었습니다!

Cloud Spanner 사용 경험과 사용된 평가 기준에 대한 포괄적인 개요를 제공하기 위해 다음 주제를 다룹니다.

1. 우리의 평가 기준
2. 간단히 말해서 Cloud Spanner
3. 우리의 평가
4. 우리의 연구 결과

1. 당사의 평가 기준

Cloud Spanner의 세부 사항, 시중의 다른 솔루션과의 유사점 및 차이점을 살펴보기 전에 먼저 인프라에서 Cloud Spanner를 배포할 위치를 고려할 때 염두에 둔 주요 사용 사례에 대해 이야기해 보겠습니다.

• (주요) 기존 SQL 데이터베이스 솔루션을 대체합니다.
• OLAP를 지원하는 OLTP 솔루션 방법

참고 : 단순성과 용이한 비교를 위해 이 문서에서는 Cloud Spanner를 GCP Cloud SQL 및 Amazon AWS RDS 솔루션 제품군의 MySQL 변형과 비교합니다.

Cloud Spanner를 기존 SQL 데이터베이스 솔루션의 대체품으로 사용

환경에서 전통적인 데이터베이스에서 데이터베이스 쿼리 응답 시간이 미리 정의된 애플리케이션 임계값에 접근하거나 이를 초과하는 경우(주로 사용자 및/또는 요청 수의 증가로 인해) 응답 시간을 허용 가능한 수준으로 줄이는 여러 가지 방법이 있습니다. 그러나 이러한 솔루션의 대부분에는 수동 개입이 필요합니다.

예를 들어, 수행해야 할 첫 번째 단계는 다양한 성능 관련 데이터베이스 매개변수를 살펴보고 애플리케이션 사용 사례 패턴에 가장 잘 일치하도록 조정하는 것입니다. 이것이 충분하지 않은 경우 데이터베이스를 수직 또는 수평으로 확장하도록 선택할 수 있습니다.

애플리케이션을 수직적으로 확장하려면 일반적으로 더 많은 프로세서/코어, 더 많은 RAM, 더 빠른 스토리지 등을 추가하여 서버 인스턴스를 업그레이드해야 합니다. 더 많은 하드웨어 리소스를 추가하면 주로 초 단위 트랜잭션 및 OLTP 시스템의 트랜잭션 대기 시간으로 측정되는 데이터베이스 성능이 향상됩니다. MySQL과 같은 관계형 데이터베이스 시스템(멀티 스레드 접근 방식을 사용)은 수직적으로 잘 확장됩니다.

이 접근 방식에는 몇 가지 단점이 있지만 가장 분명한 것은 시장에 나와 있는 최대 서버 크기입니다. 가장 큰 서버 인스턴스의 한계에 도달하면 수평 확장이라는 하나의 옵션만 남습니다.

수평적 확장은 클러스터에 더 많은 서버를 추가하는 접근 방식으로, 이상적으로는 서버 수가 추가됨에 따라 선형적으로 성능이 향상됩니다. 다수 전통적인 데이터베이스 시스템은 수평적으로 잘 확장되지 않거나 전혀 확장되지 않습니다. 예를 들어 MySQL은 슬레이브 리더를 추가하여 읽기 작업을 위해 수평으로 확장할 수 있지만 쓰기를 위해 수평으로 확장할 수는 없습니다.

반면 Cloud Spanner는 그 특성상 최소한의 개입으로 쉽게 수평 확장이 가능합니다.

모든 기능을 갖춘 서비스로서의 DBMS 다양한 각도에서 평가해야 합니다. 기본적으로 우리는 클라우드에서 가장 널리 사용되는 DBMS인 Google의 경우 GCP Cloud SQL과 Amazon의 경우 AWS RDS를 사용했습니다. 평가에서 우리는 다음 범주에 중점을 두었습니다.

• 기능 매핑: 범위 SQL, DDL, DML; 연결 라이브러리/커넥터, 트랜잭션 지원 등.
• 개발 지원: 손쉬운 개발 및 테스트.
• 관리 지원: 인스턴스 관리(예: 인스턴스 확장/축소 및 업그레이드) SLA, 백업 및 복구; 보안/액세스 제어.

Cloud Spanner를 OLAP 지원 OLTP 솔루션으로 사용

Google은 Cloud Spanner가 분석 처리용으로 설계되었다고 명시적으로 주장하지는 않지만 OLAP 워크로드용으로 설계된 Apache Impala & Kudu 및 YugaByte와 같은 다른 엔진과 일부 속성을 공유합니다.

Cloud Spanner에 (다소) 사용 가능한 OLAP 기능 세트가 포함된 일관된 수평 확장 HTAP(하이브리드 트랜잭션/분석 처리) 엔진이 포함될 가능성이 적더라도 주목할 가치가 있다고 생각합니다.

이를 염두에 두고 다음 범주를 살펴보았습니다.

• 데이터 로딩, 인덱스 및 파티셔닝 지원
• 쿼리 성능 및 DML

2. Cloud Spanner 요약

Google Spanner는 Google이 여러 자체 서비스에 사용하는 클러스터형 관계형 데이터베이스 관리 시스템(RDBMS)입니다. Google은 2017년 초에 Google Cloud Platform 사용자에게 이 기능을 일반 공개했습니다.

Cloud Spanner 속성 중 일부는 다음과 같습니다.

• 일관성이 뛰어나고 확장 가능한 RDBMS 클러스터: 하드웨어 시간 동기화를 사용하여 데이터 일관성을 보장합니다.
• 테이블 간 트랜잭션 지원: 트랜잭션은 여러 테이블에 걸쳐 있을 수 있으며 Apache HBase 또는 Apache Kudu와 달리 반드시 단일 테이블로 제한되지는 않습니다.
• 기본 키 기반 테이블: 모든 테이블에는 테이블의 여러 열로 구성될 수 있는 선언된 기본 키(PC)가 있어야 합니다. 테이블 형식의 데이터는 PC 순서대로 저장되므로 PC 검색에 매우 효율적이고 빠릅니다. 다른 PC 기반 시스템과 마찬가지로 구현은 사전 설계된 사용 사례를 염두에 두고 모델링되어야 합니다. 최고의 성능.
• 스트라이프 테이블: 테이블은 서로 물리적 종속성을 가질 수 있습니다. 하위 테이블의 행을 상위 테이블의 행과 일치시킬 수 있습니다. 이 접근 방식을 사용하면 고객 및 송장 공동 배치와 같이 데이터 모델링 단계에서 식별할 수 있는 관계 검색 속도가 빨라집니다.
• 색인: Cloud Spanner는 보조 색인을 지원합니다. 인덱스는 인덱스된 열과 모든 PC 열로 구성됩니다. 원하는 경우 인덱스에는 인덱싱되지 않은 다른 열도 포함될 수 있습니다. 쿼리 속도를 높이기 위해 인덱스를 상위 테이블과 인터리브할 수 있습니다. 인덱스에 저장되는 추가 열의 최대 수와 같은 몇 가지 제한 사항이 인덱스에 적용됩니다. 또한 인덱스를 통한 쿼리는 다른 RDBMS만큼 간단하지 않을 수 있습니다.

“Cloud Spanner는 드문 경우에만 색인을 자동으로 선택합니다. 특히 쿼리가 저장되지 않은 열을 요청하는 경우 Cloud Spanner는 자동으로 보조 색인을 선택하지 않습니다. 색인 ".

• SLA(서비스 수준 계약): SLA 99,99%로 한 지역에 배포합니다. 99,999% SLA를 갖춘 다중 지역 배포. SLA 자체는 단지 계약일 뿐 어떤 종류의 보장도 아니지만 Google 직원은 그렇게 강력한 주장을 할 수 있는 확실한 데이터를 갖고 있다고 믿습니다. (참고로 99,999%는 월 26,3초의 서비스 불가를 의미합니다.)
• 더보기 : https://cloud.google.com/spanner/

참고 : Apache Tephra 프로젝트는 Apache HBase에 향상된 트랜잭션 지원을 추가합니다(현재 Apache Phoenix에서도 베타로 구현됨).

3. 우리의 평가

따라서 우리는 높은 일관성과 매우 높은 SLA를 유지하면서 사실상 무제한의 수평 확장이 가능한 Cloud Spanner의 이점에 대한 Google의 주장을 모두 읽었습니다. 이러한 요구 사항은 어떤 경우에도 달성하기 매우 어렵지만 우리의 목표는 이를 반박하는 것이 아닙니다. 대신 대부분의 데이터베이스 사용자가 관심을 갖는 다른 사항인 패리티와 유용성에 초점을 맞추겠습니다.

샤딩된 MySQL을 대체할 제품으로 Cloud Spanner를 평가했습니다.

클라우드 시장에서 가장 인기 있는 OLTP DBMS 중 하나인 Google Cloud SQL과 Amazon AWS RDS는 매우 다양한 기능을 갖추고 있습니다. 그러나 이러한 데이터베이스를 단일 노드 크기 이상으로 확장하려면 애플리케이션 분할을 수행해야 합니다. 이 접근 방식은 애플리케이션과 관리 모두에 추가적인 복잡성을 야기합니다. 우리는 Spanner가 여러 샤드를 단일 인스턴스로 결합하는 시나리오에 어떻게 적합하고 어떤 기능(있는 경우)을 희생해야 하는지 살펴보았습니다.

SQL, DML, DDL은 물론 커넥터와 라이브러리까지 지원합니까?

먼저, 데이터베이스를 시작할 때 데이터 모델을 생성해야 합니다. JDBC Spanner를 즐겨 사용하는 SQL 도구에 연결할 수 있다고 생각한다면 이를 사용하여 데이터를 쿼리할 수는 있지만 테이블을 생성하거나 수정(DDL)하거나 삽입/업데이트/삭제하는 데 사용할 수는 없다는 것을 알게 될 것입니다. 작업(DML). Google의 공식 JDBC는 이들 중 하나를 지원하지 않습니다.

"드라이버는 현재 DML 또는 DDL 문을 지원하지 않습니다."
스패너 문서

GCP 콘솔의 상황은 그다지 좋지 않습니다. SELECT 쿼리만 보낼 수 있습니다. 다행히 커뮤니티에는 트랜잭션을 포함하여 DML 및 DDL을 지원하는 JDBC 드라이버가 있습니다. github.com/olavloite/spanner-jdbc. 이 드라이버는 매우 유용하지만 Google 자체 JDBC 드라이버가 없다는 점은 놀랍습니다. 다행히 Google은 C#, Go, Java, node.js, PHP, Python, Ruby 등 클라이언트 라이브러리(gRPC 기반)에 대해 상당히 광범위한 지원을 제공합니다.

Cloud Spanner 커스텀 API를 거의 필수로 사용하면(JDBC에 DDL 및 DML이 없기 때문에) 연결 풀이나 데이터베이스 바인딩 프레임워크(예: Spring MVC)와 같은 관련 코드 영역에 일부 제한이 발생합니다. 일반적으로 JDBC를 사용할 때 테스트를 거쳐 잘 작동하는 선호하는 연결 풀(예: HikariCP, DBCP, C3PO 등)을 자유롭게 선택할 수 있습니다. 커스텀 Spanner API의 경우 우리가 직접 만든 프레임워크/바인딩 풀/세션을 사용해야 합니다.

기본 키(PC) 중심 설계를 통해 Cloud Spanner는 PC를 통해 데이터에 액세스할 때 속도가 매우 빠르지만 몇 가지 쿼리 문제도 발생합니다.

• 기본 키 값은 업데이트할 수 없습니다. 먼저 원래 PC에서 항목을 삭제하고 새 값으로 다시 삽입해야 합니다. (이는 다른 PC 지향 데이터베이스/스토리지 엔진과 유사합니다.)
• 모든 UPDATE 및 DELETE 문은 WHERE에 PC를 지정해야 하므로 DELETE 모든 문이 비어 있을 수 없습니다. 항상 하위 쿼리가 있어야 합니다. 예: UPDATE xxx WHERE id IN (SELECT id FROM table1)
• 자동 증가 옵션이나 PC 필드의 순서를 설정하는 유사한 옵션이 부족합니다. 이것이 작동하려면 애플리케이션 측에서 해당 값을 생성해야 합니다.

보조 인덱스?

Google Cloud Spanner에는 보조 색인이 기본적으로 지원됩니다. 이는 다른 기술에는 항상 존재하지 않는 아주 좋은 기능입니다. Apache Kudu는 현재 보조 인덱스를 전혀 지원하지 않으며 Apache HBase는 인덱스를 직접 지원하지 않지만 Apache Phoenix를 통해 추가할 수 있습니다.

Kudu 및 HBase의 인덱스는 기본 키의 구성이 다른 별도의 테이블로 모델링할 수 있지만 상위 테이블 및 관련 인덱스 테이블에서 수행되는 작업의 원자성은 애플리케이션 수준에서 수행되어야 하며 올바르게 구현하는 것이 쉽지 않습니다.

Cloud Spanner 검토에서 언급했듯이 해당 색인은 MySQL 색인과 다를 수 있습니다. 따라서 쿼리를 구성하고 프로파일링할 때 필요한 곳에 적절한 인덱스가 사용되도록 특별한 주의를 기울여야 합니다.

대표?

데이터베이스에서 매우 인기 있고 유용한 개체는 뷰입니다. 이는 다양한 사용 사례에 유용할 수 있습니다. 내가 가장 좋아하는 두 가지는 논리적 추상화 계층과 보안 계층입니다. 안타깝게도 Cloud Spanner는 뷰를 지원하지 않습니다. 그러나 뷰가 실행 가능한 솔루션이 될 수 있는 열 수준의 액세스 권한에 대한 세분성이 없기 때문에 이는 부분적으로만 제한됩니다.

할당량 및 제한사항을 자세히 설명하는 섹션은 Cloud Spanner 문서를 참조하세요(스패너/할당량), 특히 일부 애플리케이션에서 문제가 될 수 있는 한 가지가 있습니다. 즉, 기본적으로 제공되는 Cloud Spanner는 인스턴스당 최대 100개의 데이터베이스로 제한됩니다. 분명히 이는 100개가 넘는 데이터베이스로 확장되도록 설계된 데이터베이스의 경우 주요 병목 현상이 될 수 있습니다. 운 좋게도 Google 기술 담당자와 대화한 후 Google 지원을 통해 이 한도를 거의 모든 값으로 늘릴 수 있다는 사실을 알게 되었습니다.

개발 지원?

Cloud Spanner는 API 작업을 위한 꽤 괜찮은 프로그래밍 언어 지원을 제공합니다. 공식적으로 지원되는 라이브러리는 C#, Go, Java, node.js, PHP, Python 및 Ruby 영역에 있습니다. 문서는 매우 상세하지만 다른 고급 기술과 마찬가지로 가장 널리 사용되는 데이터베이스 기술에 비해 커뮤니티가 매우 작기 때문에 덜 일반적인 사용 사례나 문제를 해결하는 데 더 많은 시간을 소비할 수 있습니다.

그렇다면 지역 발전을 지원하는 것은 어떨까요?

온프레미스에서 Cloud Spanner 인스턴스를 만드는 방법을 찾지 못했습니다. 우리가 얻은 가장 가까운 것은 Docker 이미지였습니다. 바퀴벌레 DB, 원칙적으로는 유사하지만 실제로는 매우 다릅니다. 예를 들어 CockroachDB는 PostgreSQL JDBC를 사용할 수 있습니다. 개발 환경은 프로덕션 환경과 최대한 유사해야 하기 때문에 Cloud Spanner는 전체 Spanner 인스턴스에 의존해야 하므로 이상적이지 않습니다. 비용을 절약하려면 단일 지역 인스턴스를 선택할 수 있습니다.

행정지원?

Cloud Spanner 인스턴스를 만드는 것은 매우 간단합니다. 다중 지역 또는 단일 지역 인스턴스 생성 중에서 선택하고 지역과 노드 수를 지정하기만 하면 됩니다. XNUMX분 이내에 인스턴스가 시작되어 실행됩니다.

Google Console의 Spanner 페이지에서 몇 가지 기본 측정항목에 직접 액세스할 수 있습니다. 측정항목 기준점과 알림 정책을 설정할 수도 있는 Stackdriver를 통해 더 자세한 보기를 사용할 수 있습니다.

자원에 대한 접근?

MySQL은 사용자 권한/역할에 대해 광범위하고 매우 세부적인 설정을 제공합니다. 특정 테이블 또는 해당 열의 하위 집합에 대한 액세스를 쉽게 구성할 수 있습니다. Cloud Spanner는 매우 높은 수준의 정책과 권한만 설정할 수 있는 Google의 ID 및 액세스 관리(IAM) 도구를 사용합니다. 가장 세부적인 옵션은 데이터베이스 수준 해결로, 이는 대부분의 프로덕션 사용 사례에 적합하지 않습니다. 이러한 제한으로 인해 Spanner 리소스의 무단 사용을 방지하려면 코드, 인프라 또는 둘 다에 추가 보안 조치를 추가해야 합니다.

백업?

간단히 말해서 Cloud Spanner에는 백업이 없습니다. Google의 높은 SLA 요구 사항은 하드웨어 또는 데이터베이스 오류, 사람의 실수, 애플리케이션 결함 등으로 인해 데이터가 손실되지 않도록 보장할 수 있지만, 우리 모두는 규칙을 알고 있습니다. 고가용성은 건전한 백업 전략을 대체할 수 없습니다. 현재 데이터를 백업하는 유일한 방법은 프로그래밍 방식으로 데이터를 데이터베이스에서 별도의 스토리지 환경으로 스트리밍하는 것입니다.

쿼리 성능?

우리는 Yahoo!를 사용하여 데이터를 로드하고 쿼리를 테스트했습니다. 클라우드 서비스 벤치마크. 아래 표는 읽기 95% 대 쓰기 비율 5%의 YCSB 워크로드 B를 보여줍니다.

* 부하 테스트는 n1-standard-32 Compute Engine(CE)(32 vCPU, 120GB 메모리)에서 실행되었으며, 테스트 인스턴스에서는 테스트에서 병목 현상이 한 번도 발생하지 않았습니다.
** 단일 YCSB 인스턴스의 최대 스레드 수는 400개입니다. 총 2400개의 스레드를 얻으려면 총 XNUMX개의 YCSB 테스트 병렬 인스턴스를 실행해야 했습니다.

벤치마크 결과, 특히 CPU 로드와 TPS의 조합을 살펴보면 Cloud Spanner의 확장성이 매우 우수하다는 것을 분명히 알 수 있습니다. 많은 수의 스레드로 인해 발생하는 과도한 로드는 Cloud Spanner 클러스터의 많은 수의 노드로 상쇄됩니다. 특히 2400개의 스레드로 실행하는 경우 대기 시간이 상당히 길어 보이지만 더 정확한 수치를 얻으려면 6개의 더 작은 컴퓨팅 엔진 인스턴스를 사용하여 다시 테스트해야 할 수도 있습니다. 각 인스턴스는 6개의 병렬 테스트가 포함된 하나의 대형 CE 인스턴스 대신 하나의 YCSB 테스트를 실행합니다. 이렇게 하면 Cloud Spanner 요청 지연 시간과 Cloud Spanner와 테스트를 실행하는 CE 인스턴스 간의 네트워크 연결로 인해 추가되는 지연 시간을 더 쉽게 구분할 수 있습니다.

Cloud Spanner는 OLAP으로서 어떻게 작동하나요?

파티셔닝?

데이터를 파티션이라고 하는 물리적 및/또는 논리적으로 독립된 세그먼트로 나누는 것은 대부분의 OLAP 엔진에서 흔히 볼 수 있는 개념입니다. 파티션은 쿼리 성능과 데이터베이스 유지 관리성을 크게 향상시킬 수 있습니다. 파티셔닝에 대한 더 자세한 내용은 별도의 기사이므로 파티셔닝 및 하위 파티셔닝 체계의 중요성에 대해 언급하겠습니다. 데이터를 여러 파티션으로 나누고 더 나아가 하위 파티션으로 나누는 기능은 분석 쿼리 성능의 핵심입니다.

Cloud Spanner는 파티션을 지원하지 않습니다. 내부적으로 데이터를 소위 말하는 것으로 나눕니다. 분열- 기본 키 범위를 기반으로 합니다. Cloud Spanner 클러스터의 부하 분산을 위해 파티션 나누기가 자동으로 수행됩니다. Cloud Spanner의 매우 유용한 기능은 상위 테이블의 기본 로드(다른 테이블과 인터리브되지 않은 테이블)를 분할하는 것입니다. Spanner는 다음 항목이 포함되어 있는지 자동으로 감지합니다. 분열 다른 데이터보다 더 자주 읽히는 데이터 분열-아, 그리고 추가 별거를 결정할 수도 있습니다. 이렇게 하면 더 많은 노드가 요청에 포함될 수 있으며, 이는 처리량도 효과적으로 증가시킵니다.

데이터를 로드 중이신가요?

대량 데이터의 Cloud Spanner 방법은 일반 로드와 동일합니다. 최대 성능을 달성하려면 다음을 포함한 몇 가지 지침을 따라야 합니다.

• 기본 키를 기준으로 데이터를 정렬합니다.
• 10*으로 나누세요노드 수 별도의 섹션.
• 데이터를 병렬로 로드하는 작업 세트를 만듭니다.

이 데이터 로드에는 모든 Cloud Spanner 노드가 사용됩니다.

우리는 YCSB 워크로드 A를 사용하여 10천만 행의 데이터 세트를 생성했습니다.

* 부하 테스트는 n1-standard-32 컴퓨팅 엔진(vCPU 32개, 120GB 메모리)에서 실행되었으며, 테스트 인스턴스에서는 테스트에서 병목 현상이 발생하지 않았습니다.
**모든 프로덕션 워크로드에는 단일 노드 설정이 권장되지 않습니다.

위에서 언급한 것처럼 Cloud Spanner는 로드에 따라 자동으로 분할을 처리하므로 여러 번 연속 테스트를 반복하면 결과가 향상됩니다. 여기에 제시된 결과는 우리가 얻은 최상의 결과입니다. 위의 수치를 보면 클러스터의 노드 수가 증가함에 따라 Cloud Spanner가 어떻게 확장되는지 확인할 수 있습니다. 눈에 띄는 수치는 매우 낮은 평균 지연 시간으로, 이는 위 섹션에 설명된 혼합 워크로드(95% 읽기 및 5% 쓰기)의 결과와 대조됩니다.

스케일링?

Cloud Spanner 노드 수를 늘리거나 줄이는 것은 원클릭 작업입니다. 데이터를 빠르게 로드하려면 인스턴스를 최대치(이 경우 미국 동부 지역의 노드는 25개)까지 늘리고 모든 데이터가 로드되면 일반 로드에 적합한 노드 수를 줄이는 것이 좋습니다. 2TB/노드 제한을 참조하는 데이터베이스입니다.

훨씬 작은 데이터베이스에서도 이러한 제한을 상기하게 되었습니다. 여러 번 로드 테스트를 실행한 후 데이터베이스 크기는 약 155GB였으며 1노드 인스턴스로 축소했을 때 다음 오류가 발생했습니다.

인스턴스를 25개에서 2개로 축소했지만 노드 XNUMX개에 갇혀 있었습니다.

Cloud Spanner 클러스터의 노드 수를 늘리거나 줄이는 작업은 REST API를 사용하여 자동화할 수 있습니다. 이는 바쁜 업무 시간 동안 증가된 시스템 부하를 줄이는 데 특히 유용할 수 있습니다.

OLAP 쿼리의 성능?

원래 우리는 이 부분에 대해 Spanner를 평가하는 데 상당한 시간을 할애할 계획이었습니다. 여러 번의 SELECT COUNT 후에 우리는 테스트 시간이 짧고 Spanner가 OLAP에 적합한 엔진이 아니라는 것을 즉시 깨달았습니다. 클러스터의 노드 수에 관계없이 10천만 행 테이블에서 행 수를 선택하는 데만 55~60초가 걸렸습니다. 또한 중간 결과를 저장하기 위해 더 많은 메모리가 필요한 쿼리는 OOM 오류로 인해 실패했습니다.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

TPC-H 쿼리에 대한 일부 숫자는 Todd Lipcon의 기사에서 찾을 수 있습니다. Nosql-kudu-spanner-slides.html, 슬라이드 42 및 43. 이 수치는 (불행히도) 우리의 결과와 일치합니다.

4. 우리의 결론

Cloud Spanner 기능의 현재 상태를 고려할 때, 특히 요구 사항이 너무 많아지면 기존 OLTP 솔루션을 간단히 대체할 수 있다고 상상하기 어렵습니다. Cloud Spanner의 단점을 해결하는 솔루션을 구축하려면 상당한 시간이 소요됩니다.

Cloud Spanner를 평가하기 시작했을 때 우리는 관리 기능이 다른 Google SQL 솔루션과 동등하거나 적어도 크게 다르지 않을 것으로 예상했습니다. 그러나 백업이 완전히 부족하고 리소스 액세스에 대한 제어가 매우 제한되어 있다는 점에 놀랐습니다. 뷰 없음, 로컬 개발 환경 없음, 지원되지 않는 시퀀스, DML 및 DDL 지원이 없는 JDBC 등은 말할 것도 없습니다.

그렇다면 트랜잭션 데이터베이스를 확장해야 하는 사람은 어디로 가나요? 모든 사용 사례에 맞는 단일 솔루션은 시장에 없는 것 같습니다. 폐쇄형 및 오픈 소스 솔루션이 많이 있으며(이 기사에서 일부 언급됨) 각각 고유한 장단점이 있지만 그 중 어느 것도 99,999% SLA와 높은 일관성을 갖춘 SaaS를 제공하지 않습니다. 높은 SLA가 주요 목표이고 커스텀 멀티 클라우드 솔루션을 구축할 의향이 없다면 Cloud Spanner가 찾고 있는 솔루션일 수 있습니다. 그러나 당신은 그것의 모든 한계를 알고 있어야 합니다.

공평하게 말하면 Cloud Spanner는 2017년 봄에야 대중에게 출시되었으므로 현재의 단점 중 일부가 결국 사라질 것이라고 예상하는 것이 합리적이며(바라건대), 그렇게 되면 게임 체인저가 될 수 있습니다. 결국 Cloud Spanner는 Google의 단순한 사이드 프로젝트가 아닙니다. Google은 이를 다른 Google 제품의 기반으로 사용합니다. 그리고 Google이 최근 Google Cloud Storage의 Megastore를 Cloud Spanner로 교체하면서 Google Cloud Storage가 글로벌 규모의 객체 목록에 대해 고도의 일관성을 유지할 수 있게 되었습니다. 아마존 S3).

그러니 아직 희망은 있습니다... 우리는 희망합니다.

그게 다야. 기사 작성자처럼 우리도 계속 희망하고 있지만 이에 대해 어떻게 생각하십니까? 댓글에 적어주세요

우리는 모든 사람을 우리를 방문하도록 초대합니다 무료 웹 세미나 그 안에서 우리는 코스에 대해 자세히 알려줄 것입니다 "개발자를 위한 AWS" 오투스에서.

출처 : habr.com