Google Cloud Spanner: 良い点、悪い点、そして醜い点

ハブロフスク在住の皆さん、こんにちは。 いつものように、新しいコースの開始に先立って興味深い内容を共有し続けます。 本日は、特に皆さんのために、コースの開始に合わせて Google Cloud Spanner に関する記事を公開しました。 「開発者のためのAWS」.

最初に出版されたのは ライトスピード本社ブログ.

Lightspeed は、世界中の小売業者、レストラン経営者、オンライン販売者にさまざまなクラウドベースの POS ソリューションを提供する企業として、さまざまなトランザクション、分析、検索のユースケースにいくつかの異なるタイプのデータベース プラットフォームを使用しています。 これらのデータベース プラットフォームにはそれぞれ独自の長所と短所があるため、Google が Cloud Spanner を市場に導入したとき、事実上無制限の水平方向のスケーラビリティや 99,999% のサービス レベル アグリーメント (SLA) など、リレーショナル データベースの世界では見られない有望な機能が提供されました。 — 私たちはそれを手に入れる機会を逃すわけにはいきませんでした！

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 バリアントと比較します。

従来の SQL データベース ソリューションの代替として Cloud Spanner を使用する

環境の中で 伝統的な データベースでは、データベース クエリの応答時間が (主にユーザー数やリクエストの増加により) 事前に定義されたアプリケーションのしきい値に近づいたり、超えたりした場合、応答時間を許容レベルまで短縮する方法がいくつかあります。 ただし、これらのソリューションのほとんどには手動介入が必要です。

たとえば、最初に実行するステップは、さまざまなパフォーマンス関連のデータベース パラメーターを確認し、アプリケーションのユースケース パターンに最もよく適合するように調整することです。 これで十分でない場合は、データベースを垂直方向または水平方向に拡張することを選択できます。

アプリケーションを垂直にスケーリングするには、通常、プロセッサ/コア、RAM、高速ストレージなどを追加することによって、サーバー インスタンスをアップグレードする必要があります。ハードウェア リソースを追加すると、主に秒単位のトランザクションで測定されるデータベース パフォーマンスと、OLTP システムのトランザクション レイテンシが向上します。 MySQL などのリレーショナル データベース システム (マルチスレッド アプローチを使用する) は、垂直方向に十分に拡張できます。

このアプローチにはいくつかの欠点がありますが、最も明らかなのは市場の最大サーバー サイズです。 最大のサーバー インスタンスの制限に達すると、残されたオプションは水平スケーリングの XNUMX つだけになります。

水平スケーリングは、より多くのサーバーをクラスターに追加するアプローチであり、理想的にはサーバーの数が追加されるにつれてパフォーマンスが直線的に向上します。 過半数 伝統的な データベース システムは水平方向にうまく拡張できないか、まったく拡張できません。 たとえば、MySQL はスレーブ リーダーを追加することで読み取り操作に対して水平方向にスケーリングできますが、書き込みに対しては水平方向にスケーリングできません。

一方、Cloud Spanner はその性質上、最小限の介入で簡単に水平方向にスケーリングできます。

フル機能 サービスとしての DBMS さまざまな角度から評価する必要があります。 基礎として、クラウドで最も人気のある DBMS (Google の場合は GCP Cloud SQL、Amazon の場合は AWS RDS) を採用しました。 私たちの評価では、次のカテゴリに焦点を当てました。

• 機能マッピング: エクステント SQL、DDL、DML。 接続ライブラリ/コネクタ、トランザクション サポートなど。
• 開発サポート: 開発とテストが簡単。
• 管理サポート: インスタンス管理 - インスタンスのスケールアップ/ダウンやアップグレードなど。 SLA、バックアップとリカバリ。 セキュリティ/アクセス制御。

OLAP 対応の OLTP ソリューションとして Cloud Spanner を使用する

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): 99,99% の SLA で 99,999 つのリージョンに導入。 99,999% の SLA を備えたマルチリージョン展開。 SLA 自体は単なる合意であり、いかなる種類の保証でもありませんが、Google の人々はそのような強力な主張を行うための確かなデータを持っていると私は信じています。 (参考までに、26,3% とは、XNUMX か月あたり XNUMX 秒間サービスが利用できないことを意味します。)
• もっと： https://cloud.google.com/spanner/

注意： Apache Tephra プロジェクトは、拡張されたトランザクション サポートを Apache HBase に追加します (これも現在はベータ版として Apache Phoenix に実装されています)。

3. 当社の評価

したがって、高い一貫性と非常に高い SLA を維持しながら、事実上無制限の水平スケーリングが可能であるという、Cloud Spanner の利点についての Google の主張を誰もが読んだことがあります。 いずれにせよ、これらの要件を達成するのは非常に困難ですが、私たちの目標はこれらの要件に反論することではありません。 代わりに、ほとんどのデータベース ユーザーが気にする他の点、つまりパリティと使いやすさに焦点を当てましょう。

Cloud Spanner を Sharded MySQL の代替として評価しました

クラウド市場で最も人気のある OLTP DBMS の XNUMX つである Google Cloud SQL と Amazon AWS RDS には、非常に多くの機能が備わっています。 ただし、これらのデータベースを単一ノードのサイズを超えて拡張するには、アプリケーションのパーティショニングを実行する必要があります。 このアプローチにより、アプリケーションと管理の両方がさらに複雑になります。 複数のシャードを XNUMX つのインスタンスに結合するシナリオに Spanner がどのように適合するのか、また、どの機能 (ある場合) を犠牲にする必要があるのか​​を検討しました。

SQL、DML、DDL のサポート、およびコネクタとライブラリ?

まず、データベースを始めるときは、データ モデルを作成する必要があります。 JDBC Spanner をお気に入りの SQL ツールに接続できると考えている場合は、JDBC Spanner を使用してデータのクエリは実行できますが、テーブルの作成や変更 (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 all ステートメントは使用できません。常にサブクエリが必要です。例: UPDATE xxx WHERE id IN (SELECT id FROM table1)
• 自動インクリメント オプションや、PC フィールドのシーケンスを設定する類似のオプションがありません。 これが機能するには、対応する値をアプリケーション側で作成する必要があります。

セカンダリインデックス?

Google Cloud Spanner にはセカンダリ インデックスのサポートが組み込まれています。 これは、他のテクノロジーには必ずしも存在しない非常に優れた機能です。 現在、Apache Kudu はセカンダリ インデックスをまったくサポートしていません。また、Apache HBase はインデックスを直接サポートしていませんが、Apache Phoenix を通じてインデックスを追加できます。

Kudu と HBase のインデックスは、主キーの構成が異なる別個のテーブルとしてモデル化できますが、親テーブルおよび関連するインデックス テーブルに対して実行される操作のアトミック性はアプリケーション レベルで実行する必要があり、正しく実装するのは簡単ではありません。

Cloud Spanner のレビューで述べたように、そのインデックスは MySQL インデックスとは異なる場合があります。 したがって、クエリとプロファイリングを構築するときは、必要な場所で適切なインデックスが使用されるように特別な注意を払う必要があります。

表現？

データベース内で非常に人気があり便利なオブジェクトはビューです。 これらは多くのユースケースに役立ちます。 私のお気に入りの XNUMX つは、論理抽象化層とセキュリティ層です。 残念ながら、Cloud Spanner はビューをサポートしていません。 ただし、ビューが実行可能なソリューションとなる可能性がある列レベルでのアクセス許可の粒度がないため、これは部分的にのみ制限されます。

割り当てと制限の詳細については、Cloud Spanner のドキュメントを参照してください (スパナ/クォータ）、一部のアプリケーションで特に問題となる可能性があるものが 100 つあります。Cloud Spanner には、初期状態ではインスタンスあたり最大 100 のデータベースという制限があります。 明らかに、これは XNUMX を超えるデータベースに拡張するように設計されたデータベースにとって大きなボトルネックになる可能性があります。 幸いなことに、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 コンソールの Spanner ページから直接アクセスできます。 Stackdriver を通じてさらに詳細なビューを利用でき、指標のしきい値やアラート ポリシーを設定することもできます。

リソースへのアクセス?

MySQL は、ユーザーの権限/ロールに対して広範囲かつ非常に詳細な設定を提供します。 特定のテーブル、またはその列のサブセットのみへのアクセスを簡単に構成できます。 Cloud Spanner は、Google の Identity & Access Management (IAM) ツールを使用します。このツールでは、非常に高いレベルでのポリシーと権限の設定のみが可能です。 最も詳細なオプションはデータベース レベルの解決ですが、これはほとんどの実稼働ユース ケースには適合しません。 この制限により、Spanner リソースの不正使用を防ぐために、コード、インフラストラクチャ、またはその両方に追加のセキュリティ対策を追加する必要があります。

バックアップ?

簡単に言うと、Cloud Spanner にはバックアップがありません。 Google の高い SLA 要件により、ハードウェアやデータベースの障害、人為的エラー、アプリケーションの欠陥などによってデータが失われないことが保証されていますが、高可用性は健全なバックアップ戦略の代わりにはならないというルールは誰もが知っています。 現在、データをバックアップする唯一の方法は、プログラムによってデータベースから別のストレージ環境にデータをストリーミングすることです。

クエリのパフォーマンス?

Yahoo! を使用してデータをロードし、クエリをテストしました。 クラウド サービスのベンチマーク。 以下の表は、95% の読み取りと 5% の書き込み比率を持つ YCSB ワークロード B を示しています。

* 負荷テストは n1-standard-32 Compute Engine (CE) (32 vCPU、120 GB メモリ) で実行され、テスト インスタンスがテストのボトルネックになることはありませんでした。
** 単一の YCSB インスタンスの最大スレッド数は 400 です。合計 2400 のスレッドを取得するには、YCSB テストの合計 XNUMX つの並列インスタンスを実行する必要がありました。

ベンチマーク結果、特に CPU 負荷と TPS の組み合わせを見ると、Cloud Spanner が非常にうまくスケールしていることがはっきりとわかります。 多数のスレッドによって生じる重い負荷は、Cloud Spanner クラスタ内の多数のノードによって相殺されます。 特に 2400 スレッドで実行している場合、レイテンシーはかなり高く見えますが、より正確な数値を取得するには、コンピューティング エンジンの 6 つの小さなインスタンスで再テストする必要がある場合があります。 各インスタンスは、6 つの並列テストを持つ XNUMX つの大規模な CE インスタンスではなく、XNUMX つの YCSB テストを実行します。 こうすることで、Cloud Spanner リクエストのレイテンシと、Cloud Spanner とテストを実行する CE インスタンスの間のネットワーク接続によって追加されるレイテンシを区別しやすくなります。

Cloud Spanner は OLAP としてどのように機能しますか?

パーティショニング？

データを物理的および/または論理的に独立したセグメント (パーティションと呼ばれる) に分割することは、ほとんどの OLAP エンジンで見られる非常に一般的な概念です。 パーティションにより、クエリのパフォーマンスとデータベースの保守性が大幅に向上します。 パーティショニングの詳細については別の記事になるので、パーティショニングとサブパーティショニング スキームの重要性についてだけ言及しておきます。 データをパーティションに分割し、さらにサブパーティションに分割する機能は、分析クエリのパフォーマンスの鍵となります。

Cloud Spanner はパーティション自体をサポートしていません。 データを内部的にいわゆる split-s は主キーの範囲に基づきます。 パーティショニングは、Cloud Spanner クラスタ内の負荷を分散するために自動的に実行されます。 Cloud Spanner の非常に便利な機能は、親テーブルのベースロード (別のテーブルとインターリーブされていないテーブル) の分割です。 Spanner は、次のものが含まれているかどうかを自動的に検出します。 split 他のデータよりも頻繁に読み取られるデータ split-ああ、そしてさらなる別れを決断するかもしれません。 こうすることで、より多くのノードをリクエストに関与させることができ、スループットも効果的に向上します。

データのロード？

一括データの Cloud Spanner メソッドは、通常の読み込みの場合と同じです。 最大のパフォーマンスを達成するには、次のようないくつかのガイドラインに従う必要があります。

• データを主キーで並べ替えます。
• 10で割ります*ノード数 別々のセクション。
• データを並行してロードする一連の作業タスクを作成します。

このデータの読み込みでは、すべての Cloud Spanner ノードが使用されます。

YCSB ワークロード A を使用して、10 万行のデータセットを生成しました。

* 負荷テストは n1-standard-32 コンピューティング エンジン (32 vCPU、120 GB メモリ) で実行され、テスト インスタンスがテストのボトルネックになることはありませんでした。
**単一ノードのセットアップは、実稼働ワークロードには推奨されません。

前述したように、Cloud Spanner は負荷に基づいて分割を自動的に処理するため、テストを数回連続して繰り返すと結果が向上します。 ここで示した結果は、私たちが得た最良の結果です。 上の数値を見ると、クラスタ内のノード数が増加するにつれて Cloud Spanner がどのように（適切に）拡張されるかがわかります。 顕著な数値は、平均レイテンシーが非常に低いことです。これは、上のセクションで説明した混合ワークロード (95% の読み取りと 5% の書き込み) の結果とは対照的です。

スケーリング？

Cloud Spanner ノードの数の増減は、ワンクリックのタスクです。 データをすばやくロードしたい場合は、インスタンスを最大までブーストし (この場合、US-EAST リージョンの 25 ノードでした)、すべてのデータがロードされたら、通常のロードに適したノードの数を減らすことを検討できます。データベース、2TB/ノードの制限を参照します。

はるかに小さいデータベースであっても、この制限があることに気づきました。 負荷テストを数回実行した後、データベースのサイズは約 155 GB になり、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 はグローバル スケールでのオブジェクトのリストの一貫性を高めることができました (これはまだ当てはまりません) Amazonの S3).

ですから、まだ希望はあります…私たちは願っています。

それだけです。 私たちも記事の著者と同じように期待し続けていますが、これについてどう思いますか？ コメントに書いてください

皆様もぜひお越しください。 無料ウェビナー その中でコースの詳細をお知らせします 「開発者のためのAWS」 オータスから。

出所： habr.com