Ten Years of Tablestore Development Summary

まえがき
Tablestore の開発は、Alibaba Cloud が創業した 2009 年に始まりました。Google Bigtable に触発され、同様の分散テーブルストレージを開発することを決定しました。
Feitian カーネルをベースに開発されているため、アーキテクチャ設計においては、Feitian プラットフォームに基づくスケーラビリティの高い分散アーキテクチャの提供、Pangu による信頼性の高いデータストレージの提供、そして何よりもクラウドベースのサービス提供を選択しました。最初のバージョンは 2010 年にリリースされ、最初のサービス顧客は Cloud Mailbox で、その大量のメールメタデータストレージをサポートしました。
2011 年半ばに Alibaba Cloud の公式ウェブサイトが正式に立ち上げられた後、その半年後の 2012 年 1 月に Tablestore のクラウドサービスが正式に公開テストを開始しました。今年で Tablestore（略称 OTS）の誕生から 13 年目、クラウドサービスとしての提供開始から 10 年目を迎えます。

クラウドサービス開発の過去 10 年間で、プロダクト機能は継続的に改善され、ビジネス規模も拡大を続けてきました。現在、Tablestore は世界中の 24 のリージョンのパブリッククラウドで提供され、数千社の企業顧客にサービスを提供しています。
また、DingTalk、Cainiao、Taote、Tmall、AutoNavi、Hema、Ant、Youku、Fliggy など、グループ内の多くの重要な BU でも利用されています。Cloud Intelligence 内部では、Cloud Monitor、MaxCompute、ファンクションコンピューティング、スマートストレージ、ビデオクラウドなど、多くのクラウドサービスの基盤となるコアストレージとしても機能しています。
現在、サービスを提供するクラスターの総規模は 1 万台を超え、数百ペタバイトのデータを保存しています。
Ali グループ内部のビジネスは、より複雑なシナリオ、より大規模なデータ、コストとパフォーマンスに対するより高い要件があるため、プロダクトにとって良い鍛錬となっています。
過去数年間、ビジネスを磨き上げ、コアを鍛え、特定の垂直シナリオで差別化された機能を進化させてきました。ビジネス規模の成長とともに安定性への課題も増大し、過去 10 年間でいくつかの大きな障害を経験しています。
安定性はストレージチーム内で常に最高優先度として位置づけられているため、アーキテクチャの継続的な最適化により可用性を向上させています。
次に、本記事ではまず Tablestore の全体像を紹介し、その後、過去数年間における機能進化、技術アーキテクチャの進化、安定性の最適化、およびビジネスレベルで定義するコアアプリケーションシナリオと代表的な事例を共有します。

プロダクト概要と開発の歩み
機能の全体像
データフロービューの全体像を通じてプロダクトを紹介します。Tablestore が提供する基本機能は分散テーブルストレージです。
このテーブルストレージには以下の特徴があります。
・パーティションテーブルモデルを提供し、ストレージ規模の水平拡張をサポート：データモデルは Bigtable の定義を参照しており、現在オープンソースコミュニティでは WideColumn に分類されます。
簡単に理解すれば大規模ワイドテーブルで、ほぼ無制限の行のデータレコードを保存でき、各行のデータには一意性を識別する行プライマリキーがあります。物理的な分布では、テーブルが行のプライマリキーの範囲に応じて異なるパーティションに分割され、これらのパーティションの分散スケジューリングを通じてスケーラビリティが提供されます。

・サーバーレスなサービス形態を提供し、より簡単に利用可能：サービスを有効化するだけで直接使用でき、ECS インスタンスを購入してサービスをデプロイする必要はありません。ユーザーからはデータストレージとリクエストのみが見え、基盤の物理リソースは非表示です。
基盤の物理リソースは、テーブルのストレージ規模とアクセス量の変化に応じて、自動的に伸縮します。
・柔軟なデータインデックスにより、データクエリと検索を高速化：Bigtable が定義するテーブルストレージモデルは行のプライマリキーにのみインデックスを持つため、非常に高速な単一行クエリとプライマリキー範囲クエリを提供できます。
しかし、実際のビジネス要件では、ユーザーは主キー以外の列に基づく条件付きクエリを実行する必要や、複数フィールドの組み合わせクエリやフルテキスト検索など、より複雑なリアルタイムクエリと検索をサポートする必要があります。そのため、その後の機能進化において Bigtable モデルを拡張し、テーブルデータのインデックス自動構築をサポートし、複数タイプのインデックス構造（セカンダリインデックスと多元インデックス、後述）を提供して、異なるクエリモードに最適化しています。

・便利なデータ管理で、データライフサイクルとデータフローを管理：データ規模が大きくなるにつれ、データ管理はより困難になります。Tablestore はより便利なデータ管理機能を提供しており、TTL による期限切れデータの自動削除、データの自動ホットコールド階層化によるコスト削減、および Tunnel Service を通じたテーブルデータの分散 CDC（変更データキャプチャ）機能により、データをリアルタイムで流通させることができます。

・完全なエンタープライズ機能を備え、より安全に利用：Tablestore はクラウド上で成長しているため、リソース管理、ネットワーク、アカウントシステム全体がクラウドベースの基盤サービスに基づいて構築されています。RAM ベースのアカウント認可、SLR ベースのサービス間アクセス認可、VPC などのプライベートネットワーク、KMS ベースの BYOK 透過的暗号化をサポートしています。

シナリオの説明
IoT デバイスの状態データストレージシナリオを例に、Tablestore のこれらの機能がどのように組み合わせて使用されるかを実際の例で確認しましょう。このシナリオでは、数億台のデバイスの状態データを保存する必要があり、各デバイスは定期的に最新の状態データを報告します。
このシナリオのテーブル構造設計は非常にシンプルで、テーブル内の各行が 1 台のデバイスのデータの保存に対応します。Tablestore にそのようなテーブルを 1 つ作成するだけで、このシナリオの基本的な機能を満たし、数億台のデバイスの状態更新、クエリ、ストレージ要件を満たすことができ、デバイス規模の増加に応じて自動的に水平方向にスケールアウトできます。
この時点で、このシナリオでより高度な機能を実装する必要がある場合：
・複数のデバイス状態属性に基づく組み合わせ条件検索の実装：API を通じてテーブルに多元インデックスを作成するだけで、テーブル内の任意のフィールドの多条件組み合わせ検索を満たすことができます。
・デバイスの最新状態変更をキャプチャしてリアルタイム計算を実行：API を通じてテーブルに分散 CDC チャンネルを作成するだけで、Flink と接続してリアルタイム計算を行うことができます。

・すべてのデバイスの状態を定期的に分析して統計レポートを生成：MaxCompute/Spark で SQL を使用して外部テーブルを作成するだけで、MaxCompute/Spark の計算エンジンを使用してテーブル内のデータのフル分析を実行できます。
Data Serving
Tablestore は構造化データストレージサービスを提供します。
アプリケーションデータで最もよく使用される構造化データストレージはリレーショナルデータベースであるため、リレーショナルデータベースとの違いは何かとよく聞かれます。データアプリケーションの観点からこの質問に答えると、リレーショナルデータベースはトランザクション処理（Transaction Process）に位置し、Tablestore はデータサービング（Data Serving）に位置します。
トランザクション処理はデータフルステートに基づくデータ処理で、データの変更にはデータ状態の整合性と一貫性を確保する必要があります。データサービングはデータのオンラインサービスをより重視し、あらゆる規模で信頼性の高い、可用性の高いデータサービスの提供を確保します。
トランザクション処理とデータサービングは実際には上流・下流の関係です。通常、アプリケーションシステムでのデータ生成はトランザクション処理のプロセスであり、データ生成後はデータサービングサービスを提供する必要があります。
実際のアプリケーションシナリオを挙げると、e コマースシステムでの各注文の生成はトランザクション処理のプロセスです。商品、価格、在庫、アカウントなどの状態データを関連付けて、注文を生成できるかどうかを判断する必要があり、完全なデータエンティティのフルステートに基づくトランザクション処理が必要です。
注文が生成された後は、データサービングの提供に切り替わります。この時点でのデータアプリケーションシナリオは、主にクエリとシンプルなデータ更新です。

開発の歩み
Tablestore の 10 年以上の開発において、機能進化の観点から主に 3 つの段階に分けています。
・段階 1.0（安定したテーブルストレージサービスの提供）：Tablestore のコア基本機能はサーバーレスなテーブルストレージサービスの提供です。
クラウドサービスとしての提供開始から最初の 5 年間、テーブルエンジン、安定性、サーバーレスプロダクト化の能力を磨き続けました。
・段階 2.0（より完全なデータサービス機能）：基本的なストレージサービス要件を満たした後、顧客からデータサービス機能に関する一連のより高い要件が提示されました。
インデックスをサポートし、より柔軟なデータクエリと検索を提供してほしい。データのリアルタイムフロー、リアルタイム計算、またはデータウェアハウスへのリアルタイム ETL をサポートしてほしい。
オープンソースの計算エンジンで直接データ分析を行えるようにしてほしい。そこで、2017 年に一連の主要機能の計画を開始し、2019 年にバージョン 2.0 をリリースして、チャネルサービス（分散 CDC）、データインデックス（セカンダリインデックスと多元インデックス）、計算エコシステムの相互接続（MaxCompute/Spark/Flink/DLA など）を公開しました。

・段階 3.0（セキュリティ、コスト、パフォーマンス、ユーザー体験）：基本的なデータサービス要件を満たした後、顧客はセキュリティ、コスト、パフォーマンス、ユーザー体験に対してより高い要件を持っています。API 呼び出しを簡素化する統一クエリ SQL をリリースし、HBR との接続によるデータバックアップと BYOK データ暗号化をサポートし、テーブルエンジンカーネルを最新バージョンにアップグレードしてパフォーマンスを大幅に向上させました。
3.0 段階は全体としてはまだ完了しておらず、一部の機能はまだ磨き上げの途中です。
進化の観点では、当初からクラウドベースのサーバーレスサービスの提供を位置づけており、この形態はビジネスの発展とともに拡張されてきました。
2015 年にはプライベートクラウドのオフライン展開により、郵便、気象、国家電網、国税、医療保険、公安などのプロジェクトに参入しました。プライベートクラウドには独自の特別なサービス形態とパブリッククラウドとは異なるサービスモデルがあり、これもプロダクト能力のもう一つの拡張です。
2016 年には海外展開を開始し、Alibaba Cloud ビジネスのグローバルデプロイをサポートしました。
技術アーキテクチャとコアコンポーネント
全体構造
・ストレージ層：基盤層は Pangu と OSS に依存します。
オールフラッシュおよびハイブリッドフラッシュの Pangu クラスターをオンラインにデプロイし、現在提供されている高性能ストレージ仕様と大容量ストレージ仕様の 2 つのタイプに対応します。低コストストレージと低頻度アクセスが必要なコールドデータには、OSS を使用して保存します。

・エンジン層：現在、テーブルエンジンとインデックスエンジンの 2 つのデータエンジンがあります。インデックスエンジンのデータはテーブルエンジンからリアルタイムで同期され、テーブル内のデータにリアルタイムでインデックスが作成されます。
2 つのデータエンジン間のデータ同期には CDC エンジンを使用しており、テーブル内のデータ更新をリアルタイムでキャプチャし、サブスクリプション機能を提供します。
・サービス層
・データインターフェイス：アプリケーションが Tablestore サービスにアクセスするための統一エントリーポイントで、すべての機能は API を通じて外部に提供されます。
基盤となるコントロールとデータインターフェイスのカプセル化に加え、この層の機能はユーザー認証、認可、フロー制御なども管理します。
・統一クエリ：SQL をクエリエンジンとして使用し、基盤のテーブルエンジンとインデックスエンジンと接続します。

Tablestore は Kuafu、Nuwa、Feitian 基礎ライブラリなど、多数の内部基盤技術を再利用しています。これらの基盤技術は他のストレージプロダクトラインで常に磨かれており、能力向上による技術的配当を直接享受できます。
Tablestore の自己開発のコア部分はエンジン層とサービス層です。次に、これらの重要なコンポーネントをそれぞれ紹介します。

分散テーブルエンジン
テーブルエンジンは Tablestore の中核です。データインデックス作成、更新サブスクリプション、データ管理はすべてテーブルエンジンを中心に構築されているため、強力なパフォーマンス、高いスケーラビリティ、安定性が必要です。
テーブルエンジンのコア技術を以下にまとめます。
・ストレージコンピューティング分離アーキテクチャ：基盤層は Pangu 分散ファイルシステムに依存し、信頼性の高いデータストレージを提供します。
ストレージとコンピューティングの分離によるメリットは、コンピューティングとストレージを柔軟に個別にスケールできることで、それぞれ強い柔軟性と弾力性を持ち、これがサーバーレスサービス提供の基盤となります。
・動的パーティショニングと自動負荷分散：パーティションはテーブルが分散機能を持つための基盤であり、動的パーティションはテーブルが弾力的な拡張機能を持つための基盤です。
テーブルの動的パーティショニング機能はパーティションの自動分割をサポートし、分割時のパーティションの不使用時間は 100 ミリ秒以内に最適化され、ユーザーリクエストにほぼ影響を与えません。自動負荷分散によるパーティションの柔軟なスケジューリングで、アクセスホットスポットを自動的に検出し排除し、リソースバランスを確保しアクセスジッターを低減します。

・高性能データエンジン：テーブルエンジンは読み書き性能を最適化するため多数の技術を採用しており、ユーザーモード通信フレームワーク（Luna）、スレッド切り替えとメモリコピーの最適化、ロックフリーデータ構造、行列混合ストレージデータブロック最適化などが含まれます。同種のオープンソースエンジンと比べてパフォーマンスが数倍向上しています。

・高可用性と安定性の最適化：可用性に影響する主なシナリオは、バーストトラフィック、負荷不均衡、Worker ノードのフェールオーバーです。グローバルフロー制御とスタンドアロンフロー制御の組み合わせでバーストトラフィックに対処し、動的負荷分散でリソースバランスを取りアクセスホットスポットを排除し、Worker ノードのフェールオーバー時間を最適化して影響を低減します。
現在、単一クラスターの可用性は 99.99% に達しています。さらに、長年にわたる障害とますます複雑化する環境でのオンライン問題は、多くのコーナーケースの問題を発見し解決することを可能にし、安定性の向上に大きく貢献しています。

分散 CDC エンジン
チャネルサービスは Tablestore が提供する CDC 機能です。CDC の正式名称は Change Data Capture で、テーブル内のデータ更新をリアルタイムでキャプチャする機能を提供します。
MySQL の Binlog、DynamoDB Stream、CosmosDB Change Feed など、多くのデータベース製品が同様の機能を提供しています。CDC は現代のデータシステムにおけるコアデータコンポーネントの必須機能の一つと言えます。
いくつかの非常に重要な用途があるからです。
・異種ストレージのリアルタイム同期：モダンなアプリケーションアーキテクチャには、データベース、キャッシュ、検索エンジン、メッセージキューなど多くの異種ストレージコンポーネントが含まれており、データはこれらのコンポーネント間をリアルタイムで流れます。
これらの異種コンポーネント間のデータ整合性を確保することが技術的な難点です。より良いアーキテクチャの実践は、唯一の DataSource をシステム全体のデータの「唯一の真実の情報源」として選択し、この DataSource の変更をキャプチャすることでリアルタイム同期を実現することです。

・イベント駆動型アーキテクチャ：イベント駆動はアプリケーションシステムのデカップリングにおける優れたアーキテクチャ実践です。複数のマイクロサービスを含む多くの複雑なアプリケーションシステムはイベント駆動技術を適用しており、たとえばメッセージキューを通じて異なるサービス間でリアルタイムかつ非同期にメッセージを配信し、完全なデカップリングを実現しています。
アプリケーション間のイベント駆動にはメッセージキューが使用されますが、データストレージとアプリケーション間のイベント駆動には CDC 技術が必要です。
・リアルタイム計算：多くのアプリケーションシナリオでデータのリアルタイム統計が必要です。
たとえば独身の日のビッグスクリーンなどです。計算のリアルタイム性能はデータフローの速度に依存し、ストレージとリアルタイム計算の接続には CDC 技術に依存してフロー速度を向上させる必要があります。

上図は Tablestore チャネルサービスのアーキテクチャを示しています。テーブルは複数のパーティションで構成され、各パーティションには Commit Log キューが含まれており、データが書き込まれた順序でパーティション内のすべてのデータ更新記録を保存します。
パーティションが分割されると、旧パーティションのキューへの書き込みが停止し、2 つの新パーティションがそれぞれの新しいキューに書き込みを開始します。チャネルサービスは本質的にパーティション内の Log キューのデータクエリを外部に開放するものですが、単にクエリインターフェイスを開放するだけでは不十分です。
チャネルサービスでは以下の重要な技術が実装されています。
・フル量・増分統合：異種ストレージ間のリアルタイムデータ同期ではデータ整合性を維持する必要があるため、まず現在のフル量データを同期してから増分データを同期する必要があります。
ログキューはフル量データを保存せず、直近のデータのみを保存するため、フル量を同期するにはテーブルを直接読み取る必要があります。チャネルサービスの基盤層はフル量と増分データのクエリをカプセル化し、外部に一貫したインターフェイスを公開することで、使用を大幅に簡素化しています。

・分散順序保証消費：データ整合性を確保する鍵は、データ変更記録の順序に厳密に従って再生できることです。単一のキューへのクエリであれば、順序保証はより簡単に達成されます。
しかし、パーティションは動的に分割されて新しいパーティションを生成するため、同じ行のデータの変更記録が異なるキューに保存される可能性があります。旧パーティションと新パーティションの間に親子関係が形成されます。
順序保証を実現するには、親パーティションを先に消費してから子パーティションを消費する必要があります。チャネルサービス内部でパーティション間の親子関係を管理し、親子パーティションの消費順序を厳密に保証できます。

・消費状態管理：チャネルサービスはデータ生産エンドを管理し、消費動作（順序保証消費など）の正確性を確保できます。しかし、コンシューマーエンドはクライアントアプリケーション内でホストされているため、コンシューマーエンドの動作を管理することは困難です。
コンシューマー側で例外が発生すると、データ消費の遅延を引き起こします。このため、チャネルサービスはサーバーサイドで消費状態管理を提供し、コンシューマー側は状態と消費統計をリアルタイムで報告します。
この状態データを使用することで、消費遅延が発生している異常ノードを迅速に特定できます。
分散インデックスエンジン
主テーブルは基本的なプライマリキーインデックスを提供しており、プライマリキーまたはプライマリキー範囲に基づくシンプルなクエリしかサポートしていません。
しかし、多くのシナリオでは主キー以外の列に基づいて条件付きクエリを実行する必要があり、インデックスを構築して高速化する必要があります。インデックスは内部的にも外部的にも構築でき、内外の組み合わせも可能です。
たとえば、MySQL は結合インデックスを提供しており、ほとんどのシナリオでクエリ高速化に対応できます。これは純粋な内部ソリューションです。
しかし、結合インデックスの使用には制限があり、クエリ条件がインデックス列の左端一致原則に従う必要があります。そのため、クエリ条件の柔軟な組み合わせが必要なシナリオでは Elasticsearch を外部インデックスとして使用する必要があります。
これは典型的な内外の組み合わせで、非常に一般的に使用されています。内部インデックスの利点は、テーブルとインデックスの整合性管理がより容易で、リアルタイム同期をより確実に保証できることです。
外部インデックスは柔軟ですが、データ整合性とデータ同期遅延の最適化において大きな課題があります。初期、Tablestore が内部インデックスを提供していなかった頃、ほとんどのユーザーが外部インデックスソリューションを選択し、同じ問題に直面していました。
そこで内部インデックスの開発を決定し、MySQL のような結合インデックスと Elasticsearch のような転置インデックスの両方を提供し、ほとんどのシナリオの要件を満たしています。
Tablestore が提供する MySQL のような結合インデックス機能はセカンダリインデックスと呼ばれ、パーティション内で強力な一貫性を提供する LocalIndex と、グローバルに結果整合性を提供する GlobalIndex を備えています。
セカンダリインデックスのデータ分布とインデックス構造はプライマリキーインデックスの実装と一致しています。論理的には、セカンダリインデックスは主テーブルデータのもう一つの次元を並べ替えたもう一つのテーブルです。
セカンダリインデックスの機能はテーブルエンジンから直接提供されます。本章では主に、Elasticsearch のような機能を持つもう一つの多元インデックスのアーキテクチャを紹介します。

上図は多元インデックスの構造を示しており、多元インデックスのコア技術を以下にまとめます。
・ストレージコンピューティング分離アーキテクチャ：基盤層は同様に Pangu 分散ファイルシステムに依存します。
多元インデックスはより多くのコンピューティングリソースを動的に割り当てる必要があるため、ストレージコンピューティング分離技術への依存度がより高くなります。
・スケーラブルなクエリ機能：多元インデックスのデータパーティションは複数のリードコピーを提供でき、これはテーブルエンジンのデータパーティションとは大きく異なります。
多元インデックスは主にクエリに最適化されているためです。リードコピーは動的拡張をサポートし、システムがクエリ負荷の高さを検出すると自動的にリードコピーを拡張でき、共有ストレージアーキテクチャにより数秒で完了します。

・データ組織の最適化：
・ハッシュパーティション：多元インデックスは不確定な複数フィールド条件の組み合わせクエリを提供するため、多くのシナリオで結果データが存在するパーティションをフィルタリングできません。通常は全パーティションの連合クエリとなり、内部的にスキャッターギャザー実行モードを採用しています。
パーティションクエリのロングテールを回避するため、パーティション間でデータをできるだけ均等にする必要があります。そのため、多元インデックスのデータパーティションはハッシュパーティション戦略を採用しており、これはテーブルの Range 戦略とは異なります。

・ルーティングキー：一部のシナリオでは、クエリ条件に固定条件フィールドが存在します。たとえば、注文インデックステーブルのクエリでは通常 userid 条件を指定します。
固定条件に基づいて事前にパーティションフィルタリングを行えれば、クエリ効率がより高くなります。そこで、ルーティングキーの戦略を提供し、ハッシュパーティションと組み合わせて使用します。
クエリ条件でルーティングキーの値を指定すると、事前にパーティションフィルタリングを行うことができます。
・事前ソート：データのソート順がクエリ結果と同じ順序であれば、全結果をクエリしてから完全ソートを行う必要がなく、必要記録数を満たす結果を取得して直接返すだけでよいため、クエリ効率が大幅に向上します。
そこで、多元インデックスは事前ソート機能を提供します。クエリ条件が常にある順序で結果を返す場合、事前ソートを定義して最適化できます。

・複数タイプのインデックス構造：B ツリー、ハッシュ、ビットマップ、BKD ツリー、転置インデックスなど、さまざまなインデックス構造があります。各インデックス構造は特定のクエリモードに最適化されています。
一般的なクエリシナリオでは、多元インデックスは数値範囲クエリを最適化する BKD ツリーインデックスと、多条件組み合わせ検索を最適化する転置インデックスを実装しています。
・適応的最適化とインデックス再構築：前述のデータ組織最適化におけるルーティングキーと事前ソート戦略は、実際のクエリモードに基づいて決定する必要があります。
多くのビジネスでは、設計時にすべての最適化戦略を事前に考慮することができません。そこで、多元インデックスは適応的最適化を提供し、一般的なクエリパターンを自動的に分析してルーティングキーと事前ソートの最適化措置を採用するかどうかを判断し、インデックスを自動的に再構築します。
これは上位レイヤーに対して完全に透過的です。
・動的インデックス列とグレースケール切り替え戦略：多くのアプリケーションシナリオでは、オンライン化後に新しいインデックス列が必要になります。
多元インデックスはインデックス列を追加する 2 つの方法を提供します。既存データに対してインデックスの再構築が必要な場合は、グレースケール切り替え戦略を提供します。
新しいインデックスはバックグラウンドでインデックスを再構築し、インデックスデータが均等化された後、トラフィックをグレースケールでクエリできます。問題がなければ切り替えまたは切り戻しを行い、新しいインデックスのオンライン化の安全性を確保します。
既存データに対してインデックスの再構築が不要な場合は、新しいインデックス列は新しいデータに対してのみ有効になります。
統一クエリエンジン
初期の Tablestore は API へのアクセスのみを提供しており、各 API は各基盤モジュールのアトミック機能に対応していました。
純粋な API の利点は、ユーザーが基盤機能を柔軟に組み合わせて呼び出すことができ、強力な DIY 能力を持つことですが、多くの不便さもあります。
・アプリケーション層のコードロジックが非常に複雑：シンプルな単一行クエリを SQL で表現すれば、主要ロジックは 1 行のコードで済みますが、API を直接使用すると少なくとも数倍のコード量が必要になります。
多元インデックスを呼び出す統計集計であれば、複雑な Group By と多層集計のコードは数十倍にも達する可能性があります。
・シンプルなデータ処理をクエリに付加できない：通常、結果データはストレージ層からクエリされた後、一部のシナリオでは元の結果を返すのではなく、Sum や Avg などの統計集計結果が必要です。
API を直接使用すると計算処理を表現できませんが、SQL を使えば簡単に軽量な統計集計をサポートできます。
・インデックスの自律的な選択と主テーブルの効率的な逆引き参照が困難：インデックス選択は RBO や CBO の最適化アルゴリズムに依存します。
アプリケーション層で自力で実装できるのはわずかなシンプルな RBO に限られ、CBO の最適化は困難です。さらに、インデックス選択の最適化アルゴリズムはサービス内に統合されるのが望ましく、各アプリケーションが個別に実装する必要がなくなります。
また、インデックスをクエリした後、主テーブルを逆引き参照するには、インデックスのクエリ API を呼び出してから主テーブルの API を呼び出す必要があり、実装が非常に複雑です。
・インタラクティブなクエリを提供できない：API を直接使用するコードデバッグではインタラクティブなクエリロジックの実装が困難で、通常は SQL によるサポートが必要です。

・MySQL を使用するアプリケーションの構成または MySQL からの移行には大量の変換コストが必要：多くのシナリオで、Tablestore は MySQL の履歴データの階層ストレージとして使用されます。テーブル構造がほぼ同じであれば、クエリロジックもほぼ同じです。
SQL をサポートしていない場合、アプリケーション層で大量のクエリコード変換コストをかけて API に適応する必要があります。
以上はすべて実際のシナリオと顧客からの実際のフィードバックに基づくものなので、慎重な検討の末、Tablestore 3.0 の計画で SQL クエリエンジンの導入を決定しました。
ただし、SQL を導入する前に、アーキテクチャ設計におけるいくつかの重要なポイントを明確にする必要があります。
・SQL はリレーショナルモデルを提供するのか、それとも連合クエリを提供するのか：SQL の位置づけは連合クエリを行うことであり、独立したモデルを表現することではありません。
主な理由は 2 つあります。1 つは Tablestore の基盤モデルがより豊富なセマンティクスを表現でき、リレーショナルモデルと完全には互換性がないこと。
もう 1 つは SQL の主な目的が連合クエリの要件を満たすことです。
・API と SQL の関係は：上記の位置づけが明確になれば、SQL と API の関係も明確になります。
SQL は API に基づいて構築されます。より正確には、API が基盤データモデルの抽象化を定義し、SQL がその上にさらに一層の抽象化を行います。

・Data Serving シナリオのコンピューティング能力要件は：技術指標として、高スループット、高 QPS、低レイテンシのクエリを提供したいと考えており、異なる SQL 実行エンジンアーキテクチャの選択と最適化目標が異なります。
・SQL エンジンの最適化目標は：上記の目標に基づき、Data Serving シナリオでの主な最適化目標は、1 つ目は水平方向にスケール可能な SQL 実行エンジンの提供、2 つ目はコンピューティング能力単位のパフォーマンス最適化であり、より多くのコンピューティング能力をスケジューリングすることではありません。

上図は SQL エンジンのアーキテクチャで、コア技術ポイントは以下の通りです。
・連合クエリ機能の提供：基盤ストレージエンジンが提供する API に基づいて構築され、API で書き込まれたデータを SQL でクエリできます。

・適応的インデックス選択と主テーブル逆引き参照：RBO と CBO に従ってインデックス選択を最適化し、主テーブルの自動逆引き参照をサポートします。
・水平方向にスケール可能な実行エンジン：API 層のアーキテクチャと同様に、ステートレスなピアノードを使用し、水平方向に拡張してより高い QPS をサポートできます。

・ユニットコンピューティング能力下でのパフォーマンス最適化：ユニットコンピューティング能力下でのコンピューティングパフォーマンスを最適化するため一連の最適化を実施しています。1. ストレージ層とのデータ交換プロトコルの最適化。
2. より多くの計算をストレージ層にプッシュダウンして実行。3. 計算エンジンの入力データに列エンコーディングを採用し、ベクトル化実行技術を適用してパフォーマンスを最適化。

コアアプリケーションシナリオ
本章では Tablestore のいくつかのコアアプリケーションシナリオを紹介します。「コア」シナリオの定義は以下の通りです。

1. そのシナリオにおいて、Tablestore がコスト、パフォーマンス、スケールの観点で一定の競争力を持つこと。
2. 既に大規模で成熟した高需要のビジネスが存在し、長年安定的に稼働し、大規模トラフィックの検証に耐えていること。

3. そのシナリオにおいて、Tablestore が一定の差別化機能を備え、アプリケーションアーキテクチャに大きなメリットをもたらすこと。
アプリケーションシナリオの分類
Tablestore 上のアプリケーションシナリオアーキテクチャのタイプを分類しました。
大まかには以下のカテゴリが含まれます。
・インターネットアプリケーションアーキテクチャ
・データベース階層化アーキテクチャ：Transaction Process + Data Serving が必要なシナリオでは、階層化アーキテクチャが採用されます。
代表的なアプリケーションは注文ストレージです。
・分散テーブルストレージアーキテクチャ：Data Serving のみが必要なシナリオでは、ストレージ層の高いスケーラビリティと高並行アクセスに対する要件が高く、Tablestore を直接使用して構築されます。
代表的なアプリケーションは、IM/Feeds メッセージストレージ、ネットワークディスクメタデータストレージ、ヘルスコードストレージなどです。
・データレイクアーキテクチャ：Bigtable の典型的なアプリケーションは、ビッグデータアーキテクチャ内のリアルタイム構造化データストレージとしての役割です。
データレイクの特徴は、ビッグデータアーキテクチャの各コンポーネントのモジュール化とサーバーレス化です。このアーキテクチャの下で、Tablestore はストリーミングバッチ計算エンジンのソーステーブル、ディメンションテーブル、結果テーブルとして使用でき、サーバーレスな構造化データストレージ機能を提供します。

・IoT アーキテクチャ：IoT は垂直的なビジネスシナリオです。大量のデバイスを管理する必要があるため、スケーラブルなストレージが必要です。
特定のアプリケーションシナリオでは、Tablestore はデバイスメッセージ、デバイスメタデータ、デバイス時系列データのストレージとして使用できます。
データプロダクトは多様に展開されており、開発者はモデル選択に頭を悩ませることが少なくありません。
モデル選択レベルでの私たちの経験は以下の通りです。
1. プロダクトが要件を満たしているかをテストする最良の方法は実際のテストです。
シンプルな機能テストだけでなく、スケールとパフォーマンスのテストも必要です。
2. 類似のアプリケーションアーキテクチャから参考にできるか確認してください。
ただし、参考にできる前提は、そのビジネスがより良いアーキテクチャを実現し、長年安定的に稼働し、大規模トラフィックの検証に耐えていることです。
3. モデル選択の誤りを恐れず、コンポーネントを置換可能な柔軟なアーキテクチャを維持することが大切です。

4. 現在のレベルでは、分散システムがビジネスの自動運用保守を実現することはまだ困難です。そのため、モデル選択時には、使用するプロダクトの背後に安定したテクニカルサポートチームがいるかも考慮する必要があります。

注文ストレージアーキテクチャ
注文ストレージは典型的なデータ階層化アーキテクチャです。2020 年に、Alibaba Cloud の財務会計システムのストレージ層の変革を支援しました。
目標は、変革後に今後 5〜10 年のスケール成長をサポートし、TP データベースから分離して請求書の検索とエクスポート時のクエリへの影響を解決することです。典型的なトランザクション処理とデータサービングの分離です。
第 1 段階では、合計 400 億件の請求書データ移行を完了し、スローインターフェイスの平均レイテンシを 7 秒から 100 ms に短縮、請求書検索パフォーマンスを 55.3 倍に向上、大規模ユーザーの請求書エクスポート速度を 35 倍に向上させました。その後、このストレージアーキテクチャをまとめ、グループ内外に複製し、さらに多くの注文ベースビジネスのストレージ変革を引き付けました。第 1 段階の完了後、第 2 段階と第 3 段階の累積データ規模は数兆件に達しています。
この階層化ストレージアーキテクチャの技術的なまとめを作成しました。公式アカウントの記事「クラウドアプリケーションシステムのデータストレージアーキテクチャの進化」を引き続きお読みいただけます。また、この大規模注文ストレージシナリオ向けのアーキテクチャ技術共有もまとめました。記事「MySQL + Tablestore 階層化ストレージアーキテクチャに基づく大規模注文システムの実践」を引き続きお読みいただけます。
メタデータストレージアーキテクチャ
メタデータはタイプとして状態データに近く、通常はトランザクション処理が必要です。しかし、一部のシナリオでは、メタデータ層はまず水平方向のスケーラビリティを持つ必要があり、トランザクションに対する要件はやや弱く、グローバルトランザクションは不要で、ローカルトランザクションのみが必要です。Ali 内部で Tablestore をメタデータストレージとして使用するビジネスにはいくつかのタイプがあり、主にネットワークディスクメタデータ、メディアアセットメタデータ、ビッグデータメタデータです。PDS サービスの基盤ストレージとして、複数の個人向けネットワークディスクビジネスを間接的にサポートしています。MaxCompute と DLF の基盤メタデータストレージとして、Alibaba 内外のビッグデータシナリオでのメタデータストレージをサポートしています。
メッセージストレージアーキテクチャ
メッセージストレージの代表的なシナリオは、主にインターネットシナリオの IM と Feeds ストリーム、および IoT シナリオのデバイスメッセージです。Ali 内部で最も重要なメッセージングアプリケーションは DingTalk、Mobile Taobao、およびアプリケーションメッセージングシステム ACCS/Agoo です。DingTalk とは 2016 年から連携を開始し、2020 年にパンデミックのピークを共に経験し、2021 年に DingTalk シーンで初めて最新版のテーブルエンジンを適用し、パフォーマンスと安定性を大幅に向上させました。DingTalk は DingTalk のメッセージング基盤に基づく IMPaaS プラットフォームを立ち上げ、Mobile Taobao のメッセージングと他のメッセージングサービスを統合しました。Tablestore は DingTalk と IMPaaS の基盤メッセージストレージとして、グループ内の多様なメッセージサービスをサポートしています。
IM と Feeds シナリオで Tablestore を使用する技術アーキテクチャ共有をまとめました。記事「現代の IM システムのメッセージアーキテクチャを設計する方法」、「メッセージシステムアーキテクチャの実装について語る」、「10 億規模の Feeds フローシステムを簡単に設計する方法」の 3 編を引き続きお読みいただけます。DingTalk も長年蓄積してきたメッセージングシステムアーキテクチャの実装を共有しています。記事「5 億ユーザーと効率的にコミュニケーションする方法？ DingTalk がインスタントメッセージングサービス DTIM の秘密を初公開」をお読みいただけます。
ビッグデータストレージアーキテクチャ
従来のビッグデータアーキテクチャはオンプレミスデプロイモデルです。クラウドに移行した後、データレイクアーキテクチャに進化し、各コンポーネントは徐々にサーバーレス化されています。最も典型的な例は HDFS を OSS に置き換えることです。従来のビッグデータには Lambda と呼ばれる古典的なアーキテクチャ体系があります。このアーキテクチャでは、データをバッチストレージとストリームストレージにそれぞれ書き込み、バッチ計算とストリーム計算を行う必要があります。その後、Kappa や Kappa+ などの新しいアーキテクチャが Lambda を簡素化しました。2 つのストレージと計算エンジンは保守の複雑さをもたらすため、後続の技術はストリームバッチ統合へと進化します。ストリームバッチ統合はさらに、Flink や Spark などの計算層でのストリームバッチ統合と、ストレージ層でのストリームバッチ統合に分かれます。Tablestore はバッチクエリと CDC ベースのストリームクエリを提供するため、ストリームバッチ統合ストレージとして機能できると判断し、Lambda Plus アーキテクチャを外部に展開し、このアーキテクチャに基づくビジネス変革も引き付けました。
Lambda Plus アーキテクチャの紹介については、記事「ビッグデータアーキテクチャはストリームとバッチをどのように統合するか」をお読みいただけます。Tablestore のビッグデータアーキテクチャにおける構造化データストレージとしての位置づけについては、記事「構造化データストレージ、どのように設計して要件を満たすか」を引き続きお読みいただけます。Tablestore はビッグデータアーキテクチャの計算エンジンのディメンションテーブルと結果テーブルとして、サーバーレスで大規模なメリットを持っています。詳細な比較がありますので、記事「クラウドネイティブビッグデータアーキテクチャのモデル実践におけるリアルタイム計算のディメンションテーブルと結果テーブルの選択」を引き続きお読みいただけます。
IoT ストレージアーキテクチャ
IoT シナリオでは、Tablestore は主にデバイスメタデータ、デバイスメッセージデータ、デバイス時系列データの保存に使用されます。コアリンクはメタデータとメッセージデータの保存です。そのアーキテクチャは上記のインターネットシナリオと似ています。インターネットシナリオで蓄積したメタデータとメッセージデータ保存の豊富な経験があるため、IoT シナリオでも十分に適用できます。時系列データは特殊なデータタイプで、タイムスタンプ付きデータ、ホットデータのリアルタイム計算、コールドデータのバッチクエリなど、いくつかの明らかな特徴があります。時系列データのスケールは大きく、ホットコールドの区別が非常に明確であるため、通常はコスト削減のためにホットコールド階層化技術を使用する必要があります。時系列データシナリオでは多くの特別な最適化が可能であることがわかったため、Tablestore 3.0 では時系列データ保存に最適化された IoTStore を開発しました。IoTStore のユースケースの紹介については、記事「ワンストップ IoT ストレージソリューション」を引き続きお読みいただけます。
最後に
お読みいただきありがとうございます。Tablestore の進化の全体像について理解を深めていただければ幸いです。まだ長い道のりが残っています。前述の全体アーキテクチャの各コンポーネントは、コスト、パフォーマンス、安定性の面でまだ改善の余地があり、引き続き完成度を追求していきます。
Tablestore がこれまで継続してこられたのは、コア研究開発チームの粘り強さだけでなく、何よりも顧客の皆様の信頼とサポートがあったからこそです。Tablestore を支えてくださるすべての顧客の皆様に感謝申し上げます。