技術革新の促進: AutoNavi データ最適化における OceanBase のベスト プラクティス

この記事の著者:

ジェンフェイ (Amap 社長)

Bingwei (AutoNavi テクニカル サービス プラットフォーム責任者)

Fuchen (Amap サーバー アーキテクト)

背景

2002 年に設立された AutoNavi は、中国を代表するモバイル デジタル地図、ナビゲーション、およびリアルタイム交通情報サービス プロバイダーであり、ナビゲーション、地域生活、配車サービス、その他のサービスを含むサービスへのワンストップの入り口をエンド ユーザーに提供しています。クラス A の測量および地図作成資格を持つ大手地図メーカーから、モバイル インターネットへの移行に成功した最初の地理情報会社、全国的な旅行プラットフォーム、そして快適な外出生活のためのオープン サービス プラットフォームまで。事業は進化してきましたが、 「旅行と生活をより良くする」というオートナビの当初の意図は変わらず、その中核となるのは地図ナビゲーションであり、データからソフトウェア、システムに至るまでの完全な研究開発能力と経験を持っています。また、人工知能、ビッグデータ、コンピューター ビジョンなどの一連の新しいスキルについても深い蓄積を持っています。

地図とは何ですか? これは、サイバー空間上の現実（物理）世界のデジタル マッピングであり、Amap の目標は「現実世界を接続し、生きた地図を作成する」ことです。今日、あらゆる階層にとって大きな関心のある概念である「デジタルとリアルの統合」は、実体経済のさらなるアップグレードと発展、能力と効率の驚異的な向上、ユーザーにとってより良い製品とサービスに対する誰もが期待していることを表しています。そして消費者。そのためには、Amapが拠点を置く運輸業界においても同様に、リアル経済とデジタル経済の高度な融合を推進することが鍵となります。当社は、「科学技術の革新を促進し、エコロジーとともに進歩する」という方針を活用して、運輸業界がデジタルと物理の統合をより適切に達成できるよう支援することに全力で取り組んでいます。

Gaode の観点から見ると、 「デジタルとリアルの統合」とはどのようなものですか? 一方で、運輸業界の本当の主体は、人、車、道路、店舗などの物理的要素であることを明らかにしており、関連分野に長年取り組んできた企業や団体こそが真のマスターであると考えています。それぞれの分野での専門性と経験が不可欠である一方、技術革新プラットフォームは、交通サービスと大規模なユーザーの間の接続、デジタル表示プラットフォーム、産業要素をデータに変換する機能を提供し、さまざまな新しい交通サービスに強力なコンピューティング機能を提供できます。オートナビは20年以上にわたり、運送業界の他分野の達人と常に連携し、彼らの専門分野を尊重し、その必要性を尊重し、深い協力関係を築き、サービスの標準技術。2022 年 10 月 1 日、中国の国慶節ゴールデン ウィーク休暇の初日、Amap は 1 日あたりのアクティブ ユーザー数が 2 億 2,000 万人という記録を達成しました。2023 年 3 月、市内通勤や都市間旅行の需要の高まりにより、Amap の 1 日平均アクティブ ユーザー数は 1 億 5,000 万人の新記録に達しました。

Amap は、継続的にユーザー エクスペリエンスを向上させ、効率を向上させ、コストを削減するために、新しいテクノロジーを常に模索し、適用してきました。

1つ目は北斗の高精度測位です。AutoNavi はテクノロジー企業として、Beidou が創業から世界クラスの企業に成長するまでの開発プロセスを目撃できることを光栄に思います。特に、2020 年に北斗 3 号のグローバル ネットワーキングが成功したことは、車線レベルのナビゲーション、インテリジェント信号機、グリーン トラベル、位置情報共有などの一連の高精度北斗テクノロジーにより、製品研究開発における新たな状況を迅速に切り開くのに客観的に役立ちました。北斗をベースにした安全性報告サービスは携帯電話にも導入され、業界内外から高い評価を得ています。現在、Amap は測位のために 1 日あたり 3,000 億回以上北斗衛星を呼び出しており、測位のための北斗の呼び出し速度は GPS などの他の衛星ナビゲーション システムを上回っています。

インターネット地図ユーザーの高度な同時アクセスと、それに伴う大量のデータの保存と処理は、対処しなければならない技術的な問題です。その中で、クラウドネイティブで業界に依存しないアーキテクチャが Amap サーバーの将来の方向性です。クラウド ネイティブは、アプリケーションとシステム環境を抽象化し、コンテナにカプセル化して、高速で信頼性が高く、スケーラブルな展開と管理を実現する新しいソフトウェア アーキテクチャ モデルです。クラウド ネイティブは将来のソフトウェア アーキテクチャの開発トレンドであり、その本質は高次元の抽象化、カプセル化です。 Amap サーバーは、生産性を向上させ、製品を迅速に反復し、ユーザーに最高のエクスペリエンスを提供するためにビジネスと協力して、クラウド ネイティブ関連テクノロジーを日々のアプリケーションの研究開発に適用することに重点を置きます。AutoNavi アプリケーションの特性に基づいて、業界に依存しないアーキテクチャが提案されています。中心となるのは、研究開発効率の問題を解決することです。ビジネス面では、より多くの業界が AutoNavi に迅速にアクセスできるようになります。技術的には、メタデータ駆動 + マルチテナントを試みています。最下層の効果は、業界から独立した構造を実現し、生産性をさらに向上させることです。

「AMAP」がユーザーにとって旅行に不可欠なツールの 1 つになるにつれ、データの保存、暗号化、高速検索、および絶対的なセキュリティが非常に重要であり、当社の取り組みの焦点となっています。必要な現実世界の情報をオンラインですぐに入手できるため、ユーザーはより快適に旅行できるようになります。その後のビジネスの発展により、間もなく兆時代に突入します。ストレージコストにせよ、データクエリのパフォーマンスにせよ、データガバナンスは特に重要であり、データの価値を迅速に発揮させてユーザーに届けなければなりません。コストを過度に浪費することなく、本物のリアルタイムデータを取得できます。

OceanBaseはアントグループが完全に独自に開発した国産ネイティブ分散データベースで、2010年に設立されました。OceanBase は、10 年連続でダブル 11 を安定的にサポートし、「3 つの場所と 5 つのセンター」という新しい都市レベルの災害復旧基準を革新的に導入し、「データベース」として知られる TPC-C および TPC-H テストで新世界記録を樹立しました。ワールドカップ"。自社開発の統合アーキテクチャは、分散アーキテクチャのスケーラビリティと集中アーキテクチャのパフォーマンス上の利点を考慮しており、一連のエンジンを使用して、OLTP と OLAP の混合負荷を同時にサポートし、強力なデータ一貫性、高いスケーラビリティ、高いデータ整合性を備えています。可用性、コストパフォーマンス、互換性の高さ、安定性と信頼性を備えたOracle/MySQLなど、企業がデータベースを利用する敷居を下げるテクノロジーが継続的に導入されています。

長期間にわたる調査、テスト、比較の結果、Amap で数兆のデータの時代を迎えるために、最もコスト効率の高い OceanBase を使用することにしました。

読者特典

現実世界では大量のデータ ストレージが存在するため、Amap は OceanBase を使用してそれを解決します。この記事では、Amap での OceanBase の実践的な体験を皆さんに見ていただけるようにします。記事全体をさまざまな観点から解釈します。全体は次のとおりです。

サーバーの観点

1) オーシャンベースを選んだ理由は何ですか?

2) Amap の実装における OceanBase アプリケーションの統合ソリューション、問題点、利点は何ですか?

3) OceanBase の Amap アプリケーションに対する将来の計画は何ですか?

読者の視点

1) AutoNavi が OceanBase を選んだ理由は何ですか?

2) AutoNavi は OceanBase をどのように使用し、その解決策は何ですか。どのような問題が発生し、どのような解決策がありますか?

3) Amap のアプリケーション シナリオにおける OceanBase のパフォーマンスはどうですか。その安定性とパフォーマンスはどうですか。また、コスト削減効果はどうですか?

4) OceanBase が独自のシナリオに基づいて解決できる問題はどれですか?

以下では、「OceanBase」の代わりに OB が使用されます。記事全体では、中心となるアイデアを実装するためのいくつかの点にも焦点を当てます。

1) OceanBase を選択した理由を理解し、OB の実装慣行を理解する

2) 分散データベースやOB関連技術の裏話を理解する

３）ツール記事として、OBにするか迷った時のヒントになります。

1.OBを選ぶ理由

Alibaba Cloud が提供するデータ ストレージ製品は数多くありますが、一般的に使用されているいくつかの製品を簡単にリストします (順不同です。含まれていないものは良くないという意味ではありません)。

• PolarDB

• リンワーム

• OB

• ES

• モンゴDB

• ...

ストレージの種類にはそれぞれ独自の特性があり、リレーショナル データベース、分散データベース、列ファミリー データベースなどがあり、いずれもさまざまなシナリオで非常に優れたパフォーマンスを発揮します。しかし、なぜOBを選んだのでしょうか？ 

実際、私たちは 2021 年から行っていることの 1 つ、それはMongoDB への移行です。従来、AutoNavi では一部のビジネスサービスのストレージとして MongoDB を使用していましたが、MongoDB の特性や設計上の特性により、CPU 使用率が高くなり、サービス Pause が正常にサービスを提供できない場合がありました。上流側の場合、タイムアウトの問題が現れ、アクセス数が多く、リトライによるラダー効果が壊滅的であれば、基本的にサービスは敗北してしまいます。多くの場合、これは MongoDB 自体の問題ではありません。MongoDB は、ドキュメントを通じてデータを維持する分散ドキュメント ストレージ システムとして定義されています。理論的には、リレーショナル シナリオには適していません。

その後、サービスは XDB、Lindorm、ES に次々と移行されました。ES を選択した理由は、低コストで安定性が高いためであり、Lindorm が異種シナリオ、キー値シナリオ、および XDB へのリクエストの侵入を減らすシナリオに非常に適しているためです。次に、データベースの選択のみが残ります。OB は NewSQL データベースですが、リレーショナル データベースの特性を保持しており、NewSQL の方法でデータを管理できます。ただし、これは、どのシナリオにも適しているという意味ではありません。構造化データ量が多いシステムにおいて、OBはコスト削減に大きなメリットをもたらします。

それで、ここで別の質問がありますか？リンドルムやESでもこのような保管はできないのでしょうか？保管と取り出しの両方が非常に効率的です。ただし、ツールの観点から見ると、Lindorm と ES は検索と異種混合検索を高速化するために使用されます。実際にはリレーショナル データベースのように使用することはできません。多くの場合、背後にデータベースがあり、データの冗長性とコストが大幅に増加します。

データベース シナリオでは、実際にはOLTPとOLAP の2 つの点に焦点を当てます。PolarDB は自然な OLTP であり、分散 MySQL エンジンの後続のアーキテクチャも OLAP 設計をサポートしています。ただし、OB 自体は NewSQL モードで設計されており、当然 OLTP と OLAP の両方のシナリオをサポートしており、ビッグ データ用の独自の圧縮システムも備えているため、コスト削減と応用において当然の利点があります。

1.1 OB基本属性情報

図1.1 OBの基本属性情報

1.2 多くの側面のバランスをとった後、OB を選択する必要がある理由を説明してください。

1) OB は、Paxos 整合性プロトコルに基づいたデータのマルチコピー ストレージ (並行して送信された複数のバージョン) であり、過半数が満たされた場合に返され、最終的に整合性が保たれます。

2) シェアードナッシング マルチコピー アーキテクチャを採用しているため、システムには単一障害点がなく、システムの継続的な可用性が保証されます。1 つのレプリカに障害が発生した場合でも、大部分は引き続き使用可能です。

3) OB は動的に拡張できます拡張後、パーティション テーブル内のデータは新しいノードに対して自動的にバランスがとられるため、上位層のビジネスに対して透過的になり、移行コストが節約されます。

4) OB ストレージは高度な圧縮機能を備えており、データを元のデータの 3 分の 1 に圧縮できるため、大規模なストレージ容量を持つ企業のストレージ コストを大幅に削減できます。

5) 疑似メモリ データベースとして、OB は LSM-Tree ストレージ エンジンを使用して増分データでメモリを操作し、ランダム書き込みを削減します。その読み取りおよび書き込みパフォーマンスは従来のリレーショナル データベースを超え、ハッシュと B+Tree をサポートします。

6) さらに重要なのは、OB は MySQL プロトコルもサポートしており、MySQL ドライバーを使用して直接アクセスできるため、基本的に OB を分散 MySQL として使用できます。

分散データベースが登場する前は、サブデータベースとサブテーブルのスキームが大量のデータの読み書きシナリオに広く使用され、サブデータベースとサブテーブル、および読み書き分離のためのミドルウェアが数多く誕生しました。これらの解決策は一定の効果をもたらす可能性がありますが、次のような後遺症を引き起こす可能性もあります。

• シャーディング ルールは事前に計画する必要があり、一度ルールを設定すると、移動したり拡張したりするのは困難です。

• 分割が細かすぎると資源の無駄が発生し、分割が粗すぎると二次分割が発生します。

• データ移行が難しい

この時点では、おそらくまだあまり経験がないと思われるため、分散データベースと OB のいくつかの技術的な観点から上記の意思決定のポイントを説明します (より適切な意思決定の便宜のため、主に対応するいくつかの点について説明します)分散データベースと OB)、技術原則を理解している学生は、直接スキップできます)。

2. クラウドネイティブ分散データベースと OB テクノロジーの裏話

2.1 クラウドネイティブデータベースの開発経緯   

クラウドネイティブ分散データベースの開発の歴史は、次の 3 つの段階を経てきました。

• スタンドアロン: 従来のスタンドアロン データベースはハイエンドのハードウェアに依存しているため、システムの拡張が難しく、コストが高くなります。

  • PG-XC: ミドルウェアベースの分散データベース (TDDL)。グローバルな一貫性、データベース間のトランザクション、複雑な SQL などの問題を解決する必要があります。

  • NewSQL: 高可用性、水平拡張、分散トランザクション、グローバル一貫性、複雑な SQL、自動負荷分散、OLAP など。

図2.1 データベース開発の歴史（画像はOceanBaseより引用）

3 つの段階から 3 つのアーキテクチャが派生しましたが、それらは NewSQL と PG-XC という 2 つの主要なスタイルに統合されました。

• MySQL でのシャーディング: 一般に、アプリケーション側またはプロキシ層でシャーディングを実行して、複数の MySQL 物理ライブラリを管理し、単一マシンの容量とパフォーマンスが不十分であるという問題を解決できます。現在使用されているTDDLはこのアーキテクチャであり、コンピューティングリソースとストレージリソースはスケーラブルですが、拡張やデータ移行の際には、ビジネスシステムレベルで多くの変換が必要となり、ビジネスデータのグレースケール化が必要となります。比較的大規模な変換が発生する可能性がある データ移行のコストとリスク。( PG-XCスタイル)

  • NewSQL: TiDB や OceanBase に代表される分散サポートをネイティブにサポートする国産リレーショナル データベースは、主に MySQL の問題を解決するように設計されています。MySQL のシャーディングとは異なり、NewSQL はデータベースの一部としてシャーディング機能を実装し、動的に拡張および縮小する機能を提供し、上位層のビジネスに対して透過的であり、透過的なスケーラビリティを備えています。

  • クラウドネイティブDB：中国のクラウドネイティブデータベースはPolarDBに代表され、プールされたリソースを持ち、ストレージリソースの動的な拡張や縮小も実現でき、一般にアクティブスタンバイ方式を採用して高可用性を実現し、同時に拡張も可能です。このような機能は外部システムに大きく依存する必要があります。( PG-XCスタイル)

図 2.2 3 つのデータベース アーキテクチャ (図は Alibaba Cloud [1] から引用)

建築体系は2つの流派に分かれる

• シャードナッシング: アーキテクチャの各ノードには独立したコンピューティング機能とストレージ機能があり、ノード間でデータは共有されません。

  • ステートレス SQL コンピューティング ノード、無制限の水平拡張

  • リモートストレージ、共有ストレージセクション

  • 強力な SQL サポート (システムが自動的にルーティングを拡張します)

  • スタンドアロンと同じトランザクションのサポート

  • データセンター間の障害からの自動復旧

  • 無制限の弾性水平拡張

  • Shard-Everying: Shard-Storage または Shared-Disk とも呼ばれ、アーキテクチャはストレージ層で統合および共有されますが、コンピューティング ノードは独立したノードです。

図 2.3 データベース アーキテクチャの 2 つの流派 (図は論文「ビッグ データ アプリケーションのための大規模データ管理システムの調査」から引用)

上の図からわかるように、Shard-Everying のストレージは共有されており、フロントに多くの計算ノードがあり、膨大なクエリ量により共有ストレージに過剰な負荷がかかり、クエリのパフォーマンスが非常に低下します。Shard-Nothing は異なります。独立したコンピューティング ノードとストレージ ノードがあり、データは共有されません。パフォーマンスは信頼できます。市場にあるほとんどの NewSQL は、Google の Spanner/F1 に従って設計されています。ここでは、Spanner の役割を簡単に紹介します。 /F1:

• F1の設計目標

  • 無制限の弾性水平拡張

  • データセンター間の障害の自己修復

  • トランザクションの ACID 一貫性

  • インデックス作成サポートによる包括的な SQL サポート

• スパナの設計目標

  • データセンター間で複製されたデータを管理する

  • データの再シャーディングとバランスをとる機能

  • データセンター間でデータを移行する

NewSQL が何であるかは、もう誰もが知っているはずです。NewSQL はリレーショナル データベースの遺伝子を完全に備えており、より強力なスケーラビリティとパフォーマンスを備えています。実際、NewSQL を分散データベースと完全に同一視することはできません。NewSQL は引き続きトランザクション ACID と SQL エンジンに従い、シームレスな移行を保証します。ただし、分散データベースは究極の一貫性を重視しており、それを NewSQL が体現すべきものです。したがって、NewSQL はネイティブ分散データベースの上に構築された「クラウド ネイティブ分散データベース」です。これは少し複雑です。次の 2 つを簡単に説明します。トランザクション モデルの一種で、通常最もよく使用されるのはトランザクション関連です。

2.2 OBの技術インサイダー情報

データベースには 3 つの主要な機能があります。上記では、OLTP の 3 つの主要な機能 (SQL 解析、トランザクション、ストレージ) のうちの 2 つ、つまりトランザクションとストレージについて紹介しました。続いてOBの技術裏話をご紹介します。次に、OLAP 上の OB のパフォーマンスについても紹介します。 

まず OLAP の 3 つの機能を紹介します。列ストレージ (幅の広いテーブルを解決するため)、圧縮 (ストレージ領域を削減するため)、ベクトル化 SIMD (単一命令複数データ)、つまり 1 つの命令で複数のデータを操作します。原理は次のとおりです。 CPUレジスタレベルでデータ並列性を実現するための操作

2.2.1 OB ストレージ エンジン

図 2.4 OB ストレージ エンジンのアーキテクチャ (画像は OceanBase から引用)

キーデザイン：

1) LSM コンセプトに基づいて自社開発した基盤となるストレージ エンジンであり、RocksDB は選択しませんでした

2) マクロブロックおよびマイクロブロックの記憶媒体 マイクロブロックはデータの組織単位であり、マクロブロックはマイクロブロックで構成されます。Compact動作中に、再利用するかどうかをマクロおよびマイクロブロックレベルで判断できます

3) 複数のパーティションと複数のコピーは、ディスク IO の競合を避けるために Compact 操作を分離します。

4) ユーザー IO/システム IO を制御してフォアグラウンド リクエストの影響を軽減する

5) 行ごとに保存、列ごとにエンコードし、ボリュームを削減

6) サイレントエラーを防ぐための圧縮の 3 つのコピーのチェックサム

7) 分散トランザクションのサポート

8) B+Tree およびハッシュ インデックス モードをサポートし、ホット データに対して多くの最適化が行われ、クエリ効率が高く、ブルーム フィルター キャッシュを使用してクエリを高速化します。

特徴:

• 行と列の混合ストレージ向けに独自に開発した低コストの圧縮アルゴリズムで、圧縮率は従来のライブラリの 10 倍以上です。

• 使いやすく、アクティブなトランザクション配置をサポートして、大規模なトランザクションの通常の実行とロールバックを保証します。パフォーマンスとスペースのバランスを取るためのマルチレベルのダンプとマージ。

• 高いパフォーマンスを実現し、マルチレベルのキャッシュを提供して低遅延を保証します。OLAP 操作はベクトル化のサポートを提供します。

• 信頼性が高く、グローバルマージ時にメインテーブルとインデックステーブル間のマルチコピー比較とチェックサム比較を行い、ユーザーデータの正確性を保証します。

データ アクセス リンク全体をカバーする複数のタイプのキャッシュ 

• データキャッシュ:

  • ブルーム フィルター キャッシュ: 静的データをキャッシュし、アクセスする必要のないデータを迅速にフィルターするブルーム フィルターを維持します。マクロブロック上の空のチェックの数が特定のしきい値を超えると、ブルームフィルター キャッシュが自動的に構築されます。 

  • 行キャッシュ: データ行キャッシュ。単一行または複数行のアクセス時に構築およびヒットします。 

  • ブロック インデックス キャッシュ: 各マクロ ブロック内のすべてのマイクロ ブロックの範囲を記述し、マイクロ ブロックをすばやく見つけるために使用されます。 

  • ブロック キャッシュ: データ ブロックにアクセスするときに構築されてヒットするマイクロ ブロック キャッシュ。 

  • Fuse Row Cache : 複数の SSTable 内のデータの融合結果。 

  • ・・・ 

• メタデータキャッシュ:

  • パーティションの場所のキャッシュ: クエリのルーティングに役立つパーティションの場所情報をキャッシュするために使用されます。 

  • スキーマ キャッシュ: データ テーブルのメタ情報をキャッシュし、実行プランの生成と後続のクエリに使用されます。

  • Clog Cache : Clog データをキャッシュし、特定の状況下で Paxos ログの取得を高速化するために使用されます。 

概要:

• 基盤となる SSTable のストレージ構造を改善し、マクロおよびマイクロブロック モードによる書き込み増幅の問題を解決し、いつでもコンパクトなタイミングを調整します。パーティションを移動するとき、基盤となるデータ ストレージ ユニットは迅速な移動に非常に適しています。

• OB 自体も基盤となるストレージを監視し、フロントエンドのリクエストが影響を受けないように Compact のタイミングを制御します。また、沈黙によるデータの混乱を防ぐために、データは Compcat で比較されます。圧縮率が高く、全体のボリュームが大きくなります。小さい。

• ストレージと、MySQL が DDL をオンラインにできない理由などについて説明します。この記事では、B+Tree と LSM のストレージの違いを主に紹介します。

2.2.2 データ複製 - Paxos

図 2.5 データ レプリケーション Paxos (画像は OceanBase から引用)

キーデザイン

1) Paxos と Raft の最も重要な違いは、ログ ホールが許可されるかどうかです。Raft は連続的である必要があり、シリアル化のみ可能ですが、並列化はできません。マルチ Paxos はログ ホールの存在を許可し、複雑なネットワーク環境に対してより堅牢です。(市場には、Beth Index を使用して Index をバッチ反復す​​るなど、Raft 用の最適化が多数あります。)

2) WAL ログ

例：

順次投票戦略は、メイン データベースに重大な悪影響を及ぼします。パフォーマンス向上のため、データベースの MVCC では、相互に関連するトランザクションを同時に処理することはできません。ただし、上記の順次投票戦略では、トランザクション #5 ～ #9 が実行されます。無関係なトランザクション #4 ブロックである可能性があり、メモリ内に保持する必要があります

ログ ホールが許可されている場合、トランザクション #5 ～ #9 は引き続き実行でき、トランザクション #4 は後で配置されます。

2.2.3 データ複製の拡張

図2.6 データレプリケーション拡張コピー型（画像はOceanBaseより引用）

キーデザイン

1)汎用コピー: トランザクション ログ、MemTable、SSTable などの完全なデータと機能がすべて含まれています。リーダーに外部サービスを提供するようにいつでもすぐに切り替えることができます。

2)ログ コピー: ログのみが含まれ、MemTable と SSTable は含まれません。投票のみに参加し、外部ログ サービスを提供します。他のコピー応答にも参加できますが、外部サービスは提供できません。

3)読み取り専用コピー: トランザクション ログ、MemTable、SSTable などの完全なデータと機能がすべて含まれています。彼のログは特別で、Paxos キャリアとして投票には参加しませんが、ログをリアルタイムで把握し、ローカルで再生するオブザーバーとして参加します。ビジネス データの整合性要件が高くない場合は、読み取り専用サービスが提供されます。

2.2.4 分散トランザクション

図 2.7 分散トランザクション (画像は OceanBase から引用)

キーデザイン： 

分散トランザクション: 2pc + GPS 線形整合性トランザクション トランザクション プロセス:

1)prepare：prepare version = max(gts,max_readable_ts,log_ts)を生成します。

2) プリコミット: ローカルの最大読み取り可能タイムスタンプを押し上げます。

3) コミット/中止: ログのマジョリティが成功した後、行ロックが解放され、クライアントが応答します。

4) clear: 参加者のコンテキストを解放します。

パーコレーターモデル

キーデザイン:

1) トランザクションの最初のパーティションはコーディネーターとして機能し、他のパーティションは参加者として機能し、トランザクションは他の参加者が戻るのを待たずにローカルで送信されます。

2) 参加者の粒度の細かい分割と少数の分散トランザクション。

図 2.8 パーコレーターのトランザクション モデル (画像は OceanBase から引用)

拡張機能:

1) 安定性を確保するための Paxos に基づくテナント レベルの GPS。

2) Truetime と同様のメカニズムを実装して、複数のトランザクションが SYS を再利用できるようにし、正確性を確保しながら圧力を軽減します。

事前に行のロックを解除します。 

最適化前: トランザクションのロック保持時間には、次の 4 つの側面が含まれます。

1) データ書き込み

2) ログのシリアル化

3) バックアップマシンのネットワーク通信を同期する

4) ログをフラッシュするのにどれくらい時間がかかりますか?

図 2.9 トランザクション最適化プロセスの分析 (画像は OceanBase から引用)

最適化:

1) ログのシリアル化が完了し、バッファ マネージャーに送信された後。

2) ログの大部分がディスクのフラッシュを完了するのを待たずにロック解除操作のトリガーを開始することで、トランザクションのロック保持時間が短縮されます。

3) トランザクションのロックが解除されると、後続のトランザクションが同じ行を操作できるようになり、複数のトランザクションの同時更新の効果が得られ、スループットが向上します。

2.2.5 ベクトル化 + 並列実行エンジン

図 2.10 OB 並列エンジンとベクトル化 (画像は OceanBase から引用)

前述したように、AP データベースの 3 つの主な機能は、ベクトル化、データ圧縮、列ストレージです。OB のエンジンは TP と AP の両方で優れたパフォーマンスを発揮し、ベクトル化エンジンと並列実行エンジンをサポートし、大規模な処理ロジックを改善します。

2.2.6 スペースの最適化 

OB のストレージは行と列が混在しています。基盤となる SSTable は複数のマクロ ブロック (マクロ ブロック) で構成されます。マクロ ブロックの長さは 2M の固定サイズであり、変更できません。マクロブロック内のデータは、マイクロブロックと呼ばれる約16KBの複数の可変長データブロックで構成されており、複数のデータ行(Row)が含まれており、データファイルの読み込みIOの最小単位となります。各データ マイクロブロックは、構築時にユーザー指定の圧縮アルゴリズムに従って圧縮されるため、マクロブロックに格納されるのは実際には圧縮されたデータ マイクロブロックです。

図 2.11 OB ストレージ エンジンのスペースの最適化 (画像は OceanBase から引用) 

行と列の混合ストレージ構造:    

SSTable は複数の固定長 (2MB) マクロブロックで構成され、各マクロブロックは複数の可変長マイクロブロックで構成されます。マイクロブロックは読み取り IO の最小単位です。OceanBase マイクロブロックには、フラット モード (Flat) とエンコード モード (Encoding) の 2 つの保存方法があります。フラット モードは通常の意味での行保存形式であり、マイクロブロック内のデータが行の順序で連続して保存されます。エンコード モード完全な行データは引き続きブロックに格納されますが、ストレージは列で編成されます。OceanBase は、データ形式とセマンティクスに基づいて複数のエンコード方法を選択し、最適な圧縮効果を実現します。同時に、実行プロセス中に、データが列編成の方法でメモリにロードされ、ベクトル化エンジンに提供されるため、HTAP の処理パフォーマンスがさらに向上します。

 

図 2.12 行と列の混合モード グラフィックスの詳細説明 (画像は OceanBase から引用)

OceanBase データベースは、辞書エンコーディング、ランレングス エンコーディング (Run-Length Encoding)、整数差分エンコーディング (デルタ エンコーディング)、定数など、実際のデータ定義に応じて選択できるさまざまな列ベースの圧縮エンコーディング形式を提供します。エンコーディング、文字列プレフィックス エンコーディング、16 進数エンコーディング、列間等価エンコーディング、列間の部分文字列エンコーディングなど、列ストレージ データベースで一般的です。

2.2.7 OLAPシナリオのサポート

上で述べたように、OLAP シナリオの 3 つの主要な機能 (ベクトル化 + 列ストレージ + データ圧縮) は、AP シナリオの大きなキラーです。上記の紹介から、OB は TP シナリオと AP シナリオの両方を満たすエンジンであることがわかります。 

• 列ストレージと行ストレージをサポート

• ベクトル化をサポート

• 並列コンピューティングをサポート

• データ圧縮をサポートし、種類に応じて異なる圧縮タイプを使用します。

唯一の問題は、AP に対する OB のサポートが特に完璧ではなく、まだ最適化中であることです。列ストレージはサポートされていますが、原則として、大きなマクロブロックには多くの小さなマイクロブロックが含まれています。マクロブロック レベルでは、データは引き続き行でスキャンされます。マイクロブロック レベルでは、マイクロブロックには複数の行が含まれる場合があり、これらの行は列に格納されます。したがって、OB アーキテクチャは依然として行ストレージ アーキテクチャであり、一部の列ストレージの利点を享受できるのはマイクロ レベルのみであり、分析パフォーマンスを完全に向上させたい場合は、徹底的な列ストレージ エンジンが必要です。

2.2.8 OB はより多くのシナリオをサポートします 

AutoNavi のビジネスは構造化シナリオと非構造化シナリオがあり、比較的多様化しているため、OB は AutoNavi のビジネスをサポートするだけでなく、さまざまな機能を備えた製品も繰り返し提供しています。

• OBノーマルモード

• OB Key-Val モード

• OB NoSQL モード

• OB ピュアカラムストレージモード

• OBサーバーレスモード

3. OB のアプリケーション固有の統合ソリューション、AutoNavi 実装時の課題と利点

OB は AutoNavi の複数のビジネス シナリオに実装されており、AutoNavi のビジネス データの安定性をサポートしています。以下では、3 つの異なるアーキテクチャでの典型的なビジネス実装シナリオを紹介します。

• 強力で一貫した財務シナリオのビジネス実装

• 大量のデータ、マルチポイント書き込みシナリオの実装

• 中央書き込み単位読み取りシナリオの実装

3.1 強力で一貫性のある財務シナリオの実装実践

事業背景と要望

図 3.1 金融決済ビジネスの構造

AutoNavi 359 の財務決済サービスは、AutoNavi の情報ビジネスの決済および財務データを主に提供しており、データの強固な整合性、データ損失のないこと、および地域をまたがる災害復旧機能が主な要件となります。

ビジネス上の課題と技術的な問題の解決

• 金融決済サービスは、B側加盟店と連携した代金計算の一環として、データの整合性に対する要求が非常に高く、データの不整合や最終的な整合性による金額計算ミスが発生することは許されません。

• 金融決済サービスのビジネスロジックは複雑であり、移行や変革のコストを削減する必要があるため、元のビジネスで使用されている SQL プロトコルと完全に互換性があり、ビジネスの大幅な変革を必要とせずに基盤となるデータベースをスムーズに置き換えることが最善です。

• 金融決済システムの強力なデータ整合性を向上させるために、3 つのコンピューター室の配置アーキテクチャが優先されました。

ビジネスアーキテクチャ図は以下の通りです 図中の赤枠の内容が今回のOBへのデータ移行に関わるシステム変換部分です XDBとOBのデータソースルーティング制御にはDiamondを使用し、OMS経由でデータ移行を行いますMAC は移行前と移行後の両方で使用されます。 データの検証。

図 3.2 決算 OB 変換設計

なぜOBを選んだのですか？

1) 財務には、データの強力な一貫性とリージョン間の災害復旧が必要であり、OB によって提供される機能はこの要件を完全にサポートします。リージョン間展開の機能により、財務データを複数のリージョンのデータ コピーに同時に書き込むことができます。リージョンが利用できない場合でも、完全なデータは引き続き利用できます。さらに、OB の Paxos 一貫性プロトコルは、応答が成功する前に OB のマルチコピー データが正常に書き込まれることを保証し、分散マルチコピー データの強力な一貫性を保証します。

2) SQL 互換性の問題を検証および解決するために、OB が提供する OceanBase Client を使用して OB にアクセスするのではなく、ネイティブ MySQL データベースの SDK ドライバーを使用して、MySQL ドライバーを介して OB にアクセスしました。 OBで再生して確認しました。

3) 金融決済システムの変換量を減らすために、さまざまな機能に従って OB テーブルを構築し、元のサブデータベースとサブテーブルの設計ロジックを OB パーティションのパーティション キー設計に適用します。テーブルを使用して、上位層のビジネスが透過的にデータを切り替えられるようにします。契約データなど、データ量が比較的安定しているディメンション テーブル データの場合、グローバルな分散トランザクションを回避し、頻繁なクエリのパフォーマンスを向上させるために、単一のテーブルとして構築されます。

• 問題解決設計の核心:

1) データを移行し、XDB (MySQL と同様) から OceanBase にデータをスムーズに移行します。

2) プロトコルの互換性。アプリケーション コードを変更せずにビジネスをスムーズに移行できるように、OB の SQL プロトコルの互換性を確認します。

移行計画の重要なポイント:

データ移行：データ移行にOMSを使用することで、グループのMACシステムを使用してデータの整合性を検証し、リアルタイムのデータ書き込みの不整合を監視およびアラームで処理します。

図3.3 金融決済システムのデータ移行設計

財務決済は副次的なビジネスではないため、強力なデータ一貫性と地域間の災害復旧に重点が置かれています。OBの配備計画の中から、コストのバランスを考慮し、決算や地域を越えた災害復旧におけるデータの整合性が得られる同一市内3室、2ヵ所3室、3ヵ所5センターの配備計画を選択しました。コストもある程度節約でき、将来必要に応じて3カ所5センター展開への迅速な拡張も可能です。

OB を完全に切り替える前に、XDB と OB の両方に完全なビジネス データがあり、毎日 MAC を通じて完全なデータを確認できると同時に、増分データの不整合をタイムリーに警察に報告することができます。同時に、XDB と OB の両方が完全なデータを保持するため、ストリームの切り替えで問題が発生した場合は、ワンクリックで元の XDB データベースに切り替えることができます。

導入アーキテクチャ

• 同じ場所に3つのコンピュータ室を配置

  • OB ネイティブ サポート機能により、同期遅延の問題を発生させることなく、データの複数のコピーを同時に書き込むことができます。

図 3.4 財務決済展開アーキテクチャ

事業収入

• ストレージの安定性、高可用性と災害復旧機能、および地域レベルを越えた災害復旧機能が向上します。

• 強力な一貫性のあるストレージ保証により、他の機能と引き換えに最終的な一貫性が損なわれるのではなく、決済データと財務データのより高い一貫性が保証されます。

• スケーラビリティとデータベースを柔軟に拡張および縮小する機能が向上します。ストレージの水平拡張は上位層システムに対して透過的であるため、データ移行のリスクが大幅に軽減されます。

• データ圧縮により、データが占有するストレージ容量が削減され、OB で使用される LSM ツリー構造はデータを元のサイズの最大 35% に圧縮できるため、ストレージ コストが削減されます。

• バランスの取れたアップグレード: OB の移行後も、MySQL ネイティブ ドライバーを引き続き使用でき、ビジネス機能開発に MySQL5.7 バージョンの SQL を使用でき、元のストレージ (XDB) プロトコルと互換性があるため、ビジネス システムの変換コストが大幅に削減されます。

• 圧力試験の結果を整理する

現在のストレス テスト データの書き込みトラフィックは約 4K で、RT は約 1ms で安定しています。

図 3.5 金融決済移行 OB 効果便益

3.2 大量データ多点書き込みシナリオの実装実践

ビジネスの背景

Amap Cloud Synchronization は、Amap の基本的なビジネス サービスであり、主にデータのクラウド ストレージとマルチデバイス デバイスのデータ同期を担当します。

図 3.6 マルチデバイスのデータ同期クラウド設計

クラウド同期ビジネス システムの導入アーキテクチャの概略図は次のとおりです: クラウド同期ビジネス ユーザーは近くに複数のアクセス ポイントを持ち、システムは 1 回のリクエストでデータベースの読み取りと書き込みを複数回行うことがわかります。システムは大量のデータ、複数の書き込みおよび読み取りポイントをサポートする必要があることがわかり、優れたパフォーマンスでデータベースを書き込みます。

図3.7 クラウド同期ユニットのシステム構成

ビジネス上の課題と技術的な問題の解決

ビジネス面では、複数の端末にデータを正確に書き込み、タイムリーに更新し、機器交換後も素早くデータを読み出せることが求められており、データ面ではオートナビの事業の急速な発展に伴い、大量のデータをクラウド上に同期保存し、ビジネスコストを大幅に削減しながら、前提として安定性を確保し、究極のパフォーマンスをいかに追求するかが、クラウド同期システムに求められる技術的課題解決のブレークスルーポイントでもあります。クラウド同期の全体的なデータベース選択要件は次のとおりです。

さまざまな場所での複数のアクティビティ、大規模なデータストレージ、低コスト

図3.8 クラウド同期選択の詳細説明

実行可能性分析

私たちのビジネス シナリオでは、原理から分析すると、OceanBase がビジネス データベースの選択要件を完全に満たしていることがわかります (詳細については、前のセクションを参照してください)。

• コスト面では、クラウド上に同期された構造化大容量データに対して、データテキスト圧縮＋行列ストレージデータ特徴量圧縮の「低コストストレージ向け高度圧縮技術」によりコストを極限まで圧縮し、大容量化するほどコストを削減します。データ量が多いほどメリットは大きくなります。

• 原理的には、LSM ツリーの基礎となるデータ構造、追加、削除、変更、バッチシーケンシャルディスク書き込みのメモリ処理により、書き込みパフォーマンスが大幅に向上し、数万の TPS データ書き込みをサポートするのに十分であり、その B+ ツリーインデックスは数百の TPS をサポートします。数千の QPS ビジネス読み取りリクエスト。

• アーキテクチャ的には、そのマルチユニット同期リンクと OMS の第 2 レベルのデータ同期機能により、複数のコンピュータ ルームでのデータ同期の低遅延が保証され、複数のコンピュータ ルームと複数のアクティビティの実現可能性がサポートされます。

• ビジネスの観点から

  • 分散ネイティブ データベースは、ビジネスの研究開発で考慮する必要があるサブデータベースとテーブルの問題を本質的に解決します。

  • ビジネス機能はマルチエンドのデータ同期であり、ID をパーティション キーとして使用でき、すべての操作が 1 つのパーティション内で完了するため、読み取りおよび書き込みのパフォーマンスが大幅に向上します。

  • 多言語 SDK はさまざまなビジネス システムをサポートし、ドッキング コストを大幅に簡素化し、SQL 形式もサポートし、構成変更時にビジネスの邪魔をしません。

図 3.9 クラウド同期移行 OB の実現可能性分析

実行計画

原則としてソリューション全体の実現可能性とビジネス上の利点を分析した後、残りはビジネス データ ソースを切り替えることです。これは主に DAO レイヤー変換、データ移行、ビジネス ボリューム拡張に分かれており、ターゲット ユーザーがデータを切り替えられるようにします。無駄のないソース。

• DAO 層のビジネス変換。OceanBase クライアントを使用してビジネス ロジック変換を実装します。

  • シンプルでユニバーサルな SDK、Java SDK のフロープログラミング、使いやすい

  • SQL ステートメント構成を必要としないビジネス

  • 呼び出しプロセス SDK カプセル化ビジネスは影響を受けません

• データ移行: 完全なデータ移行。グループの内部ツール DATAX を使用して、ID をバケットに同時にプルします。数千億のデータ全体が約 2 日で完全に同期されます。OceanBase のオフサイト バックアップおよびリカバリ機能を使用して、他のユニットへのデータ送信は数日以内に完了します。

• データ比較: この企業は、数千億のデータの日レベルの比較を実現するための数千億のデータ比較、更新、同期フレームワークと、増分/完全な比較/修復を実現するユニバーサル フレームワークを自社開発しました。

• グレースケール移行: 二重データ書き込み、ID 次元ホワイトリスト/グレースケール、比率制御をサポートし、コアは ID によるいつでもロールバックをサポートします。

図 3.10 クラウド同期移行 OB 実装計画

導入アーキテクチャ

• マルチポイント書き込み

  • 3か所での読み書き

  • ネットワーク遅延なし

• 同じ都市にあるデュアル マスター データベースを使用したディザスタ リカバリと、異なる場所にある複数のサーバーを使用したディザスタ リカバリ

  • 同一都市内でのデータベース側のディザスタリカバリ

  • 3か所の災害復旧と事業面の遮断

• 3 か所での 6 方向のデータ同期

  • 数秒以内に 3 か所で 6 方向の同期を実行

図 3.11 クラウド同期移行 OB 導入アーキテクチャ

事業収入

全体的なコスト削減は明らかであり、パフォーマンスは優れています。

パフォーマンス - ストレス テスト データ: 単一ユニットの読み取り 8wqps、3 ユニットの読み取り 24wqps、書き込み 2.8wtps、クエリでの読み取り、バッチ書き込み、平均 RT は 2 ～ 3ms です。

図 3.12 クラウド同期移行による OB 収益の結果

3.3 中央読み取り書き込みユニットの読み取りアーキテクチャの実装実践

ビジネスの背景

Amap の地図評価ビジネスには、旅行、取引、その他の決定においてユーザーを支援する明確なガイダンスがあり、レビュー範囲は POI の CTR および CVR と正の相関関係があり、地域生活戦略の文脈において、Amap の評価ビジネスの構築は Gaode De Maps の支援に役立ちます。プラットフォーム上のデータ収集からUGC時代に突入。

図3.13 評価事業効果表示

評価ビジネスの形態から判断すると、コンテンツ生成には一定の閾値があり、ライティングTPSはそれほど高くないと思われますが、オートナビの様々な入り口からコンテンツが配信されるため、RTレスポンスの需要が高くなります。読み取りが多く書き込みが少ないシナリオとしては、大規模なデータ ストレージをサポートし、遠隔地での災害復旧を提供でき、優れた読み取りおよび書き込みパフォーマンスを備えたデータベースが必要です。

ビジネス上の課題と技術的な問題の解決

• 総合評価の入り口である評価システムは、全体のRTを15ms以内に制御する必要があるという非常に厳しい性能要求を持っています。

• 読み取りパフォーマンスを向上させるために、ユーザーは通常、データを読み取る 3 つのユニットとデータを書き込むセンターで最も近い場所に接続します。データの読み取りには、リモートの災害復旧機能が必要です。

• その後のデータ量の継続的な増加をサポートする必要がある。

図 3.14 評価制度の問題点の分析

前述のビジネス シナリオの評価に従って、Amap 評価システム全体の大量の読み取りおよび書き込みをサポートするために、OB アクティブおよびスタンバイ クラスターのアーキテクチャが採用され、3 次の読み取りパフォーマンスが大幅に向上し、遅延が大幅に改善されました。アクティブとスタンバイの比率は 2 番目のレベルにあり、パフォーマンス要件を完全に満たしています。

読書用にセンターライティングユニットを選ぶ理由は何ですか?

評価のビジネス特性により、書き込み TPS はそれほど高くないと判断されます。現段階では、集中書き込みがシステム開発要件を満たすことができます。災害復旧機能の点では、マルチサイト書き込みの方が優れていますが、一連の書き込みが発生します。データの競合やより複雑な問題など。総合的なシステムとビジネスの開発段階では、中央書き込みユニット読み取りのソリューションを選択しました。

オーシャンベースを選ぶ理由?

複数のデータベースをコストやアーキテクチャ上の特徴などの観点から水平的に比較し、最終的にOceanBaseを選択しました。

• ビジネス面では、ビジネスの発展とデータ量の増加に伴い、データストレージのボトルネックを解決する必要がありますが、OB の優れた水平拡張機能により、この問題をうまく解決できます。

• コストの面では、OceanBase が独自に開発した行-列混合ストレージ構造/高効率デジタルエンコーディングに基づくストレージ圧縮技術によりコストを極限まで圧縮し、評価データのストレージコストを効果的に削減できます。

• 原理的には、LSM-Tree に基づく基礎となるデータ構造は書き込みパフォーマンスを大幅に向上させ、評価シナリオの書き込み要件を満たすのに十分です。B+ ツリーに基づくインデックスは、評価シナリオにおける大規模な読み取りのクエリ要件を満たすことができます。

• アーキテクチャ的には、OceanBase マスターおよびバックアップ データベース アーキテクチャに基づいており、クラスターのネイティブ レプリケーション機能を利用して、第 2 レベルの同期と高い信頼性を実現します。

導入アーキテクチャ図

• 中央書き込み

• 中央の書き込みユニットが読み取りを行うため、アーキテクチャがよりシンプルになり、データ範囲を心配する必要がありません。

• 同じ都市内のデュアルマスターのディザスタリカバリと、異なる場所にある複数のマスターのディザスタリカバリ

• 同じ都市内の複数のコンピュータ室の災害復旧とフロー遮断

• 3 か所での災害復旧

• 3 か所でのプライマリ データとセカンダリ データの同期

• クラスター間のネイティブ同期機能を利用して、第 2 レベルの同期を実現します。

図 3.15 評価システム導入アーキテクチャ

コアポイント:

• Zhangbei Center のメイン クラスタは読み取りおよび書き込み可能であり、強力な一貫性のある読み取りを実現します。

• 上海と深センはバックアップ クラスターであり、OB のネイティブ クラスター レプリケーション機能を通じて、同期と第 2 レベルのレイテンシーが実現され、強整合性のない異種ストレージに対して高トラフィックで時間のかかる読み取りサービスが実現されます。

データの一貫性の保証:

• リアルタイム: OB マスターとバックアップ間のクラスターのネイティブ同期機能により、信頼性は非常に高く、基本的に心配する必要はありません。

• オフライン: オフライン分析の包括的な手段を提供し、MAC プラットフォームでの T+1 分析を通じてデータの一貫性を監視します。

• 遅延監視: OB マスターとスレーブは、クラスターのネイティブ マスター/スレーブ同期遅延監視機能を通じて監視され、クラスター レベルのレプリケーション機能は高性能であり、通常の遅延は 2 番目のレベルにあります。

OB アクティブおよびスタンバイ クラスターを使用した上記のアーキテクチャは、Amap 評価システム全体の大量の読み取りおよび書き込みをサポートし、3 次の読み取りパフォーマンスが大幅に向上し、アクティブおよびスタンバイのレイテンシは完全に 2 番目のレベルに達しました。性能要件を満たしています。

インデックス設計の実践

大量のデータを扱う C サイドのシナリオでは、データ シャードの水平方向のストレージ拡張を実現するために、基本的にパーティション テーブルを確立する必要があります。次に、パーティション シナリオにおけるインデックスの設計について説明します。評価シナリオの核となるモデルは基本的な評価情報であり、その他の評価タグ、評価要素、評価スコアなどは評価IDによって関連付けることができるため、効率的なクエリを実現するためのインデックスの設計方法を中心に説明します。メイン評価テーブル (appraise_base)。

(1) パーティションキーの設計:

最初は評価 (appraise_id) をパーティション キーとして使用しました。

partition by key(appraise_id) partitions 512

この設計の考慮点は、評価 ID で分割することでデータが比較的均一に分散され、同時に高頻度のクエリも評価 ID で実行されるということであり、このソリューションは比較的従来的でユニバーサルな設計ですが、表面的には問題はないようです。しかし、オンライン トラフィックに基づく実際の圧力テストでは、期待された結果が達成されていないことが判明しました。私たちは、OB クラスメートと一緒に、冷静になってその理由を分析し始めました。

ビジネス トラフィックを分析すると、ほとんどのクエリは appraiser (appraiser_id) ディメンションにあることがわかりました (ビジネス シナリオは、ユーザーが POI の最初のレビュー担当者であるかどうかをクエリすることであり、POI の詳細ページにはユーザーの最新のレビューが表示されます)。これらのクエリはすべてなくなりました。グローバル インデックス。グローバル インデックスのシナリオでは、インデックスとデータは必ずしも同じノード上にあるわけではありません。ほとんどのリクエストはクロスマシン分散トランザクションを経由する必要があるため、より多くのデータベース リソースが消費されます。

オンライン クエリ トラフィックの分析:

• ユーザー ディメンションの単一およびバッチ クエリ (75% を占める)

• レビュー ID によるクエリ (15% を占める)

• 時間別の評価対象ディメンションクエリ/ページクエリ（10%を占める）

現時点では、問題の原因は比較的明らかです。パーティション設計に欠陥があるため、多数のクエリが非効率なインデックスに向けられ、全体的なパフォーマンスが向上できません。これは、パーティションの非常に重要な原則につながります。メイン SQL ディメンションでの設計確立パーティション キー! パーティションインデックスのパフォーマンスは最高です。

したがって、パーティション キーは appraiser (appraiser_id) ディメンションに作成されます。

partition by key(appraiser_id) partitions 512

(2) 指数の設計

パーティション キーが決定された後、通常、他のディメンションのクエリはグローバル インデックスに設定され、パーティション キー ディメンションの複数条件クエリはローカル インデックスに設定されます。具体的には次のようになります。

PRIMARY KEY (`appraise_id`, `appraiser_id`),
KEY `idx_appraiser_id_gmt_create` (`appraiser_id`, `gmt_create`) BLOCK_SIZE 16384 GLOBAL,
KEY `idx_targetid_gmt_create` (`appraise_target_id`, `gmt_create`) BLOCK_SIZE 16384 GLOBAL,
KEY `idex_modified_status` (`gmt_modified`, `status`) BLOCK_SIZE 16384 GLOBAL
partition by key(appraiser_id)

• Appraiser ID ディメンション (appraiser_id) はパーティション キーを設定します

• 鑑定ID(appraise_id)を主キークエリとして設定

• オブジェクト ディメンションの評価 (appraise_target_id) はグローバル インデックス クエリを設定します

idx_appraiser_id_gmt_create のインデックス設定が少し無理が​​あることがわかりましたか? インデックスはグローバル インデックスに設定されています。パフォーマンスが向上するローカル インデックスに設定できます。理由は次のとおりです: appraiser_id はすでにパーティション キーであり、シャードはルーティングされていますappraiser_id までのすべての量が保持されます。データはローカル インデックスを通じて完全に検索できます。グローバル インデックス クエリを実行する必要はありません。このインデックスは最終的にローカル インデックスに変更されました。

KEY `idx_appraiser_id_gmt_create` (`appraiser_id`, `gmt_create`) BLOCK_SIZE 16384 LOCAL,

(3) パーティションテーブル配下のデータ更新

ビジネスでは評価ID(appraise_id)で評価データを更新しますが、実際のストレステストではCPU使用率が70%程度まで上昇することが判明し、appraise_idで更新する際にパーティションキーが無いことが調査の結果判明しました。パーティションを見つける際の追加コストであるため、更新中にパーティション キーが条件に追加され、同じ圧力下で CPU が 20% 未満に低下します。

評価システムのインデックス設計の概要は次のとおりです。 パーティション テーブルのシナリオでは、適切なインデックス設計を行うことが非常に重要です。

図 3.16 評価システム指標設計実践の概要

事業収入

• 新しいデータベース アーキテクチャは、コメント システム全体の読み取りおよび書き込みパフォーマンスを完全にサポートします。

• 分散データベース。データベースやテーブルの再シャーディングにつながる、その後の大量のデータ増加を心配する必要はありません。

• 全体的なストレス テストの結果は次のとおりです。読み取り/書き込み 2 時間、平均応答は 1 ～ 2 ミリ秒で安定しています。





図3.17 評価システム移行OB特典結果

4. AutoNavi での着陸における OB のベスト プラクティスの概要

4.1 OB を選ぶ理由

2章ではOBの技術裏話、3章ではAutoNavi OBの導入シナリオをそれぞれお話しますが、なぜOBを選ぶのかを詳しく考えると、データベースの選択はどのように考えればよいのでしょうか。「すべてはビジネスシナリオに基づいており、異なるデータベースは異なるビジネスに適しています。 」と言いたいのですが、ビジネスに小さなシナリオしかなく、数十万のデータ、数百のQPSクエリがあり、データは基本的に増加しません。クラウド同期ビジネス (セクション 3.2) を見ると、クラウド同期ビジネスの特徴は次のとおりです: 単位化、大規模なデータ ストレージ、大量のリクエスト、そしてクラウド同期はMongo->Lindorm->OceanBase. Why is it maigled? Why not use MySQL at the same time? では、次のように比較します。

PS: 弊社のビジネスにおいてリレーショナル データベースと NoSQL データベースの両方を検討している理由については、弊社のビジネスは本質的に構造化データであり、リレーショナル データベースに適していますが、全体的なビジネス クエリはシンプルであり、NoSQL や KV も弊社のビジネスをサポートできるからです。

表4.1 データベース選択の属性情報

私たちが最も懸念している 3 つの点:安定性、ビジネス サポート、コスト。これら 3 つの観点を考慮すると、OceanBase が最適なソリューションです。データベースを決定した後、OceanBase の導入アーキテクチャを選択する必要があります。

4.2 OceanBase 導入アーキテクチャの選択

上記のプロジェクトの実践からわかるように、リモート マルチアクティブ デプロイメントには 2 つのアーキテクチャ (マルチポイント書き込み、中央書き込み、およびマルチユニット読み取り) を使用しています。同じことは、2 つの異なるアーキテクチャを使用する OceanBase にも当てはまります。

4.2.1 アーキテクチャの選択 - マルチポイント書き込み

マルチポイントライト導入アーキテクチャでは、3台のデータベースが互いに独立しており、OceanBaseが提供するデータ同期ツールOMSを利用して、3箇所6方向で相互に同期することができます。以下に続きます:

• ユーザーは最も近いユニットにアクセスし、データの遅延なく対応するユニットの読み取りと書き込みを行うことができます。

• ユーザーに損失を与えることなく、完璧なリモート マルチ アクティビティ、各ユニットのリモート ディザスタ リカバリ、およびマシン ルーム障害発生時のデータ遮断をいつでも実現します。

図 4.1 OB ユニットの展開アーキテクチャ

4.2.2 アーキテクチャの選択 - 集中書き込みユニット読み取り

中央書き込みユニット読み取りシステム アーキテクチャには、OceanBase のマスター/スレーブ アーキテクチャが主に使用され、全体的な利点は次のとおりです。

• 全体的な読み取りサポート容量は 3 倍になり、ネットワーク時間を節約できます。

• マスター/スレーブ アーキテクチャはクラスターの内部メカニズムであり、自動的に同期され、運用とメンテナンスが簡素化されます。

  

図 4.2 OB の中央書き込みユニット読み取りアーキテクチャ

4.2.3 アーキテクチャの選択 - 同じ都市内の複数のコンピュータ室での読み取りと書き込み

• ユーザーリクエストからビジネスシステムまでの不可避な物理的遅延（30～50ms）

• 同じ都市内の複数のコンピュータ室の災害復旧は、遠隔地での災害復旧機能に匹敵することはできません。

• シンプルなアーキテクチャと便利な操作とメンテナンス

4.2.4 複数台のデータ同期について

実際、OMS は中央書き込みや単位読み取りにも使用できますが、必須ではありません。

表4.2 複数台のデータ同期比較

4.2.5 アーキテクチャ選択に関する結論

結論: 異なる構造を使用することには、さまざまな利点と欠点があります。採用する具体的なアーキテクチャは、ビジネス要件によって異なります。ビジネスに読み取りレイテンシに対する強い要件がない場合は、アクティブ モードとバックアップ モードを使用できます。そうでない場合は、マルチ モードを使用できます。ユニット OMS 同期モードが選択され、ターゲット自体がユニット化されます。クラウド同期ビジネスには、多点書き込みが最適です。

4.2.6 多点筆記システムの問題点と解決策

マルチポイント書き込みシステム (セクション 3.2 のクラウド同期システムの例) に関しては、次のような多くの疑問があります。

• クラウド同期システムの業務はユニット化する必要があるのでしょうか？ユニット化しないと何が問題になるのでしょうか？

• コストを考慮してユニット化されていますが、3台ではデータを全て保存できないのでしょうか？

• ユニット化されたシステムの災害復旧に問題はありますか?

4.2.6.1 クラウド同期システムをユニット化する必要があるのはなぜですか?

ビジネス背景分析:

(1) ビジネス要件の観点から見ると、1 つのリクエストに対して、クラウド同期システムはデータベースと複数回やり取りする必要があり、ネットワークの遅延を減らすために、データベースは張北、上海、深センの 3 つのセンターにある必要があります。

(2) ユーザーのアクセスに関しては、APP アクセスを通じて、現在の方法は最も近い場所にアクセスすることですが、ユーザーの 2 つの連続したリクエストはセンターをまたぐ可能性があります。

(3) 3 つのユニットのデータベースの同期には必ず遅延が発生します。これは減らすことしかできませんが、避けられないものです (ネットワークの物理的な遅延など)。

異常な状況の例 (データの欠落と上書きの詳細については 4.2.7.2 を参照):

ユーザーが同じデータの変更を 2 回続けて要求し、その要求がセンターをまたいだ場合 (1 回目は張北センター、2 回目は上海センター) はどうなりますか?

(1) 張北のアップデートに対するユーザーの最初のリクエストは成功しました。

(2) ユーザーの上海アップデートの 2 回目のリクエストは成功しました。

(3) 2 つのリクエストの間隔が同期遅延未満の場合、データの同期後、上海センターの最新データが張北センターのデータで上書きされ、張北センターの最新データが上書きされます。上海センターのデータで上書きされます 上書きするとデータに不整合が生じます

ユニット化により解決される問題:

(1) ユーザーのリクエストを同じ中央ユニットにまとめて、起こり得るデータの不整合の問題を解決します。

(2) ユーザーがネットワーク遅延を生成するのは最大 1 回です。エントリー層が配布用のユーザー ユニットを識別すると、そのデータは他のユニットに転送される可能性があります。ビジネスとデータベース間の複数の対話によって追加のネットワーク遅延が発生することはありません。

4.2.6.2 ユニット化されたシステムの各ユニットが完全なデータを保存する必要があるかどうか

(1) コスト面では、ユニット化されたシステムは対応するユニットデータを保存するだけでデータの同期が不要であると同時に、保存コストが非常に低い（メリット）。

(2) しかし、3 台​​は不完全なデータを保管しているため、災害復旧や遮断ができず、同一都市内の災害復旧はデータベースに頼るしかなく、複数のアクティブな災害を提供することはできません。回復場所が異なる（デメリット）。

結論: ディザスタリカバリのためのシステムの安定性要件に依存しますが、異なる場所でマルチアクティビティを実現し、いつでもディザスタリカバリに切り替えるには、各ユニットに全量のデータを保存する必要があります。

4.2.6.3 ユニット化されたシステムの災害復旧やフロー遮断に問題はありますか?

ユニット化されたシステムにより、日常的な状況ではデータの整合性の問題は解決されますが、システムが災害復旧や停止に見舞われた場合には、依然としてデータの整合性の問題が発生するため、さらに解決する必要があります。

図 4.3 ユニット化された展開の同期遅延

4.2.7 フローカット状態でのデータ欠落およびカバレッジの解決策

4.2.7.1 データはどのような状況で欠落しますか?

データの不足を理解するのは簡単です。ユーザーがあるユニットから別のユニットに切り替えます。前のユニットのデータが書き込まれたばかりで、同期リンクの遅延により、ユーザーが他のユニットに切り替えましたが、以前のユニットのデータが書き込まれたばかりの場合書き込まれたデータはまだ書き込まれていないため、データが欠落するように同期してください。

4.2.7.2 どのような状況でデータが上書きされますか?

これは極端な状況ですが、実際に起こる可能性もあります。下図に示すように、ユーザーが最初に 1 を実行し、次に 2 を実行し、実行 1 と実行 2 の間でユーザー単位の切り替えが発生した場合、データ遅延が大きい場合はどうなりますかユーザーの操作よりも？これによりデータに永続的な差異が生じ、Zhangbei OB でデータ エラーが発生します。

• Zhangbei OB の場合、データが遅延した場合、2 が最初に処理され、1 が同期リンクを通じて処理され、最後のデータは id = 1 name = 'a' になります。

• 深セン OB の場合: 1 が最初に実行され、2 が後で実行され、最終データは id = 1 name = 'b' になります。

 

図 4.4 データカバレッジ問題の詳細な説明

4.2.7.3 解決策は何ですか?

• ビジネス側は書き込み禁止時間を保証し、OMS に長時間の遅延が発生しないことを要求します。

• OMS データが同期されると、データが上書きされないことが保証されます (現在、OMS は開始と停止後のデータの再追跡をサポートしており、タイムスタンプが比較されます)。そのため、OMS の開始と停止をフローに統合しました。カットプラン。

• OMS 遅延が短いほど、リスクは小さくなります。

図 4.5 データ上書き回避設計

4.2.7.4 OMS同期を通じて遅延を削減する方法

OMS 同期リンクの分割と相互独立。

同期リンクはデータベース ディメンションからテーブル ディメンションに分割できます。相互のリンクは独立しており、影響を与えませんが、同期のパフォーマンスは向上します。

図 4.6 OMS による遅延の削減方法

4.2.7.5 OMS による遅延の影響の軽減

すべてのテーブルを 3 つの独立したリンクにダウングレードした後のテスト データの結果は、ピーク書き込み速度が 100 Mbit/s で、同期遅延が 10 秒から 20 秒の間であることを示しました。

図 4.7 OMS 遅延削減効果 (注: 機密データのため、一部のデータは感度が低くなります)

4.3 OceanBase の場合、パーティション化されたテーブルを選択する必要がありますか? それとも単一のテーブルを選択する必要がありますか?

4.3.1 ビジネス設計の選択 - パーティション化されたテーブルまたは単一テーブル

• ビジネスが急速に成長している場合は、パーティション分割テーブルを選択する必要があります。

• OceanBase の現在の最大パーティション数は 8192 であり、パーティションの数は作成時に固定されており、自動的に並べ替えることはできないことに注意してください。



図4.8 OB テーブルの設計と選択の詳細な説明

4.3.2 ビジネス設計の選択 - グローバルインデックスまたはローカルインデックス

• ローカル インデックス: インデックスとデータは同じパーティション化ルールを持ち、同じマシン上にあるため、一部の分散トランザクションを回避できます。

• グローバル インデックス: グローバル パーティション インデックスであっても、グローバル非パーティション インデックスであっても、インデックスとデータが同じマシン上に存在しない可能性があり、各書き込みはマシン間分散トランザクションとなります。つまり、グローバル インデックスはテーブル データの書き込みパフォーマンスに影響を与えます。

4.3.2.1 グローバルインデックスの使用シナリオ

• 主キーに加えてグローバルな一意性に対する強い要件があり、グローバルに一意なインデックスが必要です。

• クエリ条件にはパーティション述語がなく、高い同時書き込みもありません。グローバル スキャンを回避するために、グローバル インデックスを構築できますが、通常は 4 つのグローバル インデックスに制限されます。

4.3.2.2 グローバルインデックスとローカルインデックスのパフォーマンスの比較



図 4.9 OB インデックス間のパフォーマンスの比較[2]

引用元: https://www.zhihu.com/question/400141995/answer/2652474150

4.3.2.3 ローカルインデックスの読み書き時の注意事項

ローカルインデックスの読み書きの場合、リクエスト時にパーティションキーを指定する必要があるため、OceanBaseによる実際の処理中に対応するパーティションが直接決定され、全​​体的なパフォーマンスに大きな差が生じます。たとえば、更新シナリオでパーティション キーがヒットすると、CPU 使用率が 75% から 20% 未満に低下しました。

4.3.2.4 グローバルインデックス使用時の注意事項

1) グローバル インデックスを使用する場合、スキャンされる行数が多すぎることを避ける必要があります。スキャンされる行数が多すぎると、多数の RPC 呼び出しが発生し、結果として RT が高くなりすぎます。大規模なクエリはバッチでクエリすることをお勧めします。

2) 更新操作にグローバル インデックスを使用することは推奨されません。グローバル インデックスの更新パフォーマンスの比較に基づくと、QPS が高いとシステム負荷が比較的高くなります。

4.3.3 ビジネスデザインの選択 - OBKV または OB 通常バージョン

OBKV 版と OB 通常版について一言で説明します。OBKV 版には SQL 解析オプティマイザーがありません。多くの SQL では SQL の最適化やインデックスの指定などを企業が手動で行う必要がありますが、KV 版は通常版よりも安価です。

表 4.3 OB バージョン間のコスト比較

PS: 現在、OBKV バージョンは SDK を提供し、Java/Go/Rust 言語をサポートしています。

4.3.4 ビジネス設計の選択 - レプリケートされたテーブルをいつ使用するか?

レプリケート テーブルの概念: OceanBase にはレプリケート テーブルと呼ばれるテーブル タイプがあります。この種のテーブル データは、パーティション テーブルのようにシャード化されず、単一テーブルのように単一のオブザーバーにのみ保存されることもありません。代わりに、すべてのデータは完全に保存されます。すべてのオブザーバーで。

主な利点: レプリケートされたテーブル データがすべてのオブザーバーに存在するため、データベースはクエリ プランを作成するときに対象を絞った最適化を実行して、データがローカル マシンから確実に取得され、リモート呼び出しが回避されるようにします。

使用シナリオ: 特定のテーブルのデータが非常に少なく、このテーブルがビジネス目的で他のパーティション テーブルと多数の JOIN クエリを実行する必要がある場合、このテーブルにレプリケーション テーブルを設定して JOIN パフォーマンスを向上させることができます。一般的な例として、システムには都市テーブル、カテゴリ テーブルなどの基本的なデータ テーブルがいくつかあります。そのようなテーブルを他のテーブルと JOIN する必要がある場合は、クロスパーティションを避けるためにそれらをレプリケート テーブルとして設定することを検討できます。 . 参加してください。

4.3.5 ビジネス設計の選択 - リーダーのコピーをさまざまなオブザーバーに配布する必要がありますか?

OceanBase のゾーンには通常 3 つの Observer ノードがあり、デフォルトでは、システム内のすべてのパーティション テーブルのリード コピーは 1 つのノードのみに分散されます。オブザーバーでは、このオブザーバーは、このゾーン内のすべての読み取りおよび書き込みリクエストに耐えることができます。リーダーのコピーをすべてのオブザーバーに配布することを検討できます。これにより、システム全体のリソース使用率が向上します。しかし、これは他の問題も引き起こす可能性があり、システム内でパーティションをまたがる読み取りおよび書き込み操作が多数ある場合、大量のリモート呼び出しが追加され、読み取りおよび書き込み RT が増加します。    

ほとんどの場合、システムのデフォルト構成を使用するだけですが、データベースのパフォーマンス上の問題が発生した場合にのみ、リーダー コピーの分割を検討し、ストレス テストを実施して効果を検証します。使用シナリオは次のように要約されます。

分散リーダー コピー: システム内のほとんどのクエリはローカル インデックスを使用して完了できますが、グローバル インデックスを使用するクエリはわずかで、システム内の書き込み操作に分散トランザクションが使用されるシナリオはそれほど多くありません。

リーダー コピーを分散しない: システム内に一定の割合のグローバル インデックスまたは書き込み分散トランザクションが存在する場合、分散によりこれらの読み取りおよび書き込み操作の RT が増加します。

4.3.6 ビジネス設計の選択 - 主キーとパーティションキーの設定

主キー: 従来のリレーショナル データベースの代替として、Oceanbase はビジネス システムのメイン データベースとして OLTP シナリオでよく使用されます。このシナリオでは、後のメンテナンスやデータの異質性などを容易にするために、自動インクリメント主キーを使用することをお勧めします。Oceanbase には独自の自己増加主キーが付属していますが、パーティション内の単調性のみを保証できるため、推奨されません。「データベース番号セグメント モード」や「スノーフレーク アルゴリズム」などの外部分散 ID ソリューションを使用することをお勧めします。

パーティションキー:

1) Oceanbase パーティショニング方法は非常に柔軟で、マルチレベル パーティショニング、ハッシュ関数パーティショニング、レンジ関数パーティショニングをサポートしており、通常は特定のフィールドに基づいてハッシュ パーティショニングを使用します。  

2) パーティション キーを選択するときは、クエリ メソッドとデータ ホットスポットの問題を包括的に考慮する必要があります。通常、ほとんどのクエリで最高のパフォーマンスが得られるように、最もクエリの多いディメンションをパーティション キーとして使用できます。

3) システム内に互いに密接な関係があり、JOIN で一緒に使用されることが多いテーブルのグループがある場合、このテーブルのグループは同じパーティション化方法を使用し、同じパーティション数を設定できます。データベースは、このテーブルのグループのデータ分散は、同じシャードの下、同じオブザーバー上にあります。たとえば、注文テーブルと注文詳細テーブルの両方で、ユーザー ID をパーティション キーとして使用できます。

4) シャードの数は適切である必要があります。シャードが大きすぎるとクエリのパフォーマンスに影響します。これは独自のシナリオに従って設定し、検証のためにテストする必要があります。

4.4 事業実施におけるボトルネック

クラウド同期などの大量の読み取りと書き込み、および休日の旅行のピークを考慮すると、トラフィックが 2 倍になる可能性がありますが、ストレス テストの結果、いくつかのボトルネックが見つかりました。

4.4.1 ボトルネック - トラフィックがわずかに高く、クライアントは明らかにエラーを報告し、タイムアウトします。

• Java クライアント コードに問題があり、リクエスト処理リンクを開始するときに、Synchronized が不当に使用されます。

• 最新のパッケージにアップグレードすると、問題が解決される可能性があります。

図4.10 ボトルネッククライアントの遅延問題

4.4.2 ボトルネック - 読み取りおよび書き込みトラフィックの増加、明らかなビジネス タイムアウト

• ストレス テストが増加すると、平均 RT が大幅に増加し、失敗のタイムアウトも大幅に増加します。

• 理由: プロキシ側のパフォーマンスのボトルネック。

図 4.11 読み取りおよび書き込みトラフィックが増加し、サービス タイムアウトが明らかです (注: 機密データのため、一部のデータは感度が低くなります)

4.4.3 ボトルネック - 業務マシンの拡張に失敗し、データベースに接続できない

• 拡張に失敗すると、データベースに接続できないというメッセージが表示されます。

• ビジネス システムは再試行を繰り返しますが、依然として接続できません。

その理由は、単一のプロキシ リンクの数には上限があるためです。

4.4.4 ボトルネックの解決 - 大規模データ クラウド上の展開アーキテクチャの最適化

OceanBase パブリック クラウドの通常の展開アーキテクチャは、左側の図 4.4.3 に示すように、クライアント -> SLB -> プロキシ -> OBServer ですが、大量のデータ要求に対してボトルネックが発生する可能性があります。また、読み取りおよび書き込みのパフォーマンスがビジネス リクエストをサポートするには十分ではありません。現時点では、アーキテクチャを最適化し、水平分割を実行できます。OMS を使用して、複数ユニットの OBServer 間のデータ同期を行うことができます。高 TPS 書き込みの場合、大量のデータが同時に書き込まれる場合、OMS を分割することもできます。通常、この場合、同期リンクは 2 つのデータベース間の完全な同期をサポートし、最適化されたアーキテクチャをテーブルのディメンションに分割して相互に同期できます (次を参照)。詳細についてはセクション 4.2.7.4 を参照してください)。

図 4.12 大規模なリクエストに対する OceanBase の水平分割

4.4.5 業務実施の最適化効果

過去の旅行のピーク時、クラウド同期ビジネスのピーク時の OceanBase の全体的な RT は 2 ～ 3 ミリ秒で安定していました。

図 4.13 大規模なデータ遅延の最適化効果 (注: データの感度により、一部のデータは感度が低くなります)

4.5 もちろん、いくつかの落とし穴も経験しました。

4.5.1 OB KV バージョンは SQL オプティマイザをサポートしていないため、インデックスの使用をプログラムで指定する必要があります。

OBKV バージョン: 最大限のパフォーマンスの最適化を達成するために、複雑なクエリを使用しないビジネスでは、OB KV バージョンを使用します。このバージョンでは、プログラムの仕様が必要な SQL 最適化インデックスを自動的に選択する機能はサポートされていません。例は次のとおりです:

「item_uid」、「item_id」の結合インデックスを作成しました。ビジネスで OB KV のインデックス作成を使用する必要がある場合は、コード行 6 のように、indexName を指定する必要があります。

TableQuery query = obTableClient.query(table).setScanRangeColumns("item_uid", "item_id");
            for (String itemId : itemIdSet) {
                query.addScanRange(new Object[]{uidStr, itemId}, new Object[]{uidStr, itemId});
            }
            QueryRESultSet rESults = query
                    .indexName(INDEX_UID_ITEM_ID)
                    .execute();

同時に、上で述べたように、リクエストにはパーティション キーを指定する必要がありますが、これを使用する場合はパーティション キーの指定に注意する必要があります。ここでのパーティション キーは uid です。

public TableQuery queryWithFilter(int uid, String table, ObTableFilterList filterList) {
        return obTableClient
                .query(table)
                .setScanRangeColumns("uid")
                .addScanRange(uid, uid)
                .setFilter(filterList);
    }

4.5.2 OMS の詰まりが失われ、OMS 同期が大幅に遅延し、アラームがトリガーされる

セクション 4 の冒頭のマルチポイント書き込みセクションでは、3 か所で 6 方向データ同期のアーキテクチャが紹介されています。OMS にはストア ノードがあり、ストア ノードのデータはメモリに保存されます。ストレス テスト中に、次のことがわかりました。データを書き込むときの量が多すぎると、メモリの上書きが発生し、その結果、同期ログが失われ、詰まります。この解決策は、ログの永続性を確保するために、メモリ + ログ ディスクです。ディスクがいっぱいの場合はどうすればよいですか? 現時点では、ディスクのマージンは比較的大きく、ディスク関連のアラームも同時に追加されるため、勤務担当者がいつでもそれに注意を払うことができます。

図 4.14 OMS データリンク

4.5.3 Amap の上海バックアップ クラスターのマスター/スレーブ アーキテクチャは、スケールダウン後はサービスを提供できません。

ビジネス ソリューション チームは、問題が発見されるとすぐにビジネスを遮断し、ビジネス全体に影響を与えることはありませんでした。これは、遠隔地での複数のアクティビティの重要性を反映しており、迅速な災害復旧も可能です。

• 直接の理由: クラスターがスケールダウンされ、SLB がスタンバイ クラスターをサポートしない OBProxy バージョンに切り替えられたため、サービスが利用できなくなりました。

• 根本原因: パブリック クラウド上の OB クラスターの OBProxy は、デフォルトでオブザーバーと同じマシンにデプロイされます。3 月初旬に、アクティブ データベースとスタンバイ データベースおよび POC テストをサポートするために、OBProxy デプロイ モードが独立して切り替えられました。アクティブ データベースとスタンバイ データベースのインスタンスとバージョンのデプロイメントはサポートされますが、メタ情報のレコードは変更されません (まだ混合モードです)。その結果、この縮小プロセス中に、コロケーション モードを認識した後、SLB によってマウントされている OBProxy 情報を変更する必要があると考えられ、プライマリ データベースとスタンバイ データベースをサポートしていない現在のバージョンにマウントされるようになりました。ビジネスアクセスが異常でした。

問題解決

• OBProxy の運用および保守運用の自動最適化: 運用漏れによって引き起こされるその後の問題を回避し、さまざまなバージョンの OBProxy クラスターの作成、OBProxy への SLB バインディングなどをサポートします。

• ノードの解放操作に新しいサイレント期間が追加されました。問題が発生した場合は、すぐにロールバックできます。

4.5.4 OceanBaseServer 一部のノードの CPU がいっぱいです

症状: ある日の正午に突然アラームが発生し、CPU がフルロードになり、全体的な現象は図 4.5.2 および 4.5.3 に示すとおりです。

図 4.15 OB 異常ノード CPU (注: 機密データのため、一部のデータは非感作されています)

図 4.16 OB 通常ノードの CPU (注: 機密データのため、一部のデータは非感作されています)

問題分析: Alibaba Cloud SQL 分析により、データベースにいくつかの遅いクエリと大量の KILL QUERY リクエスト レコードがあることが判明しました。

図 4.17 Cloud SQL 分析の CPU 問題の影響 (注: 機密データのため、一部のデータは感度が低くされています)

問題の原因:

問題のある SQL のビジネス シナリオ: 作業指示書 ID を使用して作業指示書のコールバック レコードをクエリし、逆順で 100 件のレコードをフェッチします。

テーブル a から gmt_create,id を選択します (a.フィードバック_id=xxxx)。 gmt_create asc,id DESC 制限 100 で注文します。

PRIMARY KEY (`feedback_id`, `id`),
KEY `idx_gmt_create_id` (`gmt_create`, `id`) BLOCK_SIZE 16384 LOCAL
partition by hash(feedback_id)

この SQL には 2 つの実行プランがあります。

プラン A: 主キー インデックスを使用し、フィードバック ID ディメンションの主キー インデックスをクエリします (フィードバック ID はパーティション キーです)。

プラン B: ローカル インデックス idx_gmt_create_id を使用し、feedback_id ディメンションでローカル インデックス クエリを実行します。

通常であれば、作業指示書（小さいID）のコールバックレコードは数十件あり、実行計画はAです。しかし、その日はたまたま作業指示書に何らかの異常が発生し、下流側がコールバックを送信し続けました。メッセージ、およびコールバック レコードが 50,000 (大きな ID) に達しました。)、この時点で、OB エンジンはプラン B のパフォーマンスが優れていると判断します。OB 実行プランの排除メカニズムに従って、一定期間の実行プランが切り替えられます。プランBへ。このとき、小さい ID クエリもプラン B に切り替えられました。小さい ID SQL は idx_gmt_create_id ローカル インデックスを使用するため、パフォーマンスが低下し、タイムアウトが発生し、アプリケーションが大量の KILL クエリを開始し、最終的に CPU が満杯。

ID が小さいとローカル インデックスのパフォーマンスが低下する理由:

ソートによるパフォーマンスの問題であることを OB に確認してください。具体的には、現在の 3.2.3.3 バージョンの前方ソートのパフォーマンスは最適化されています。現在のバージョンの逆ソートは最適化されていないため、降順ソートに 5 秒以上かかります。 。大きな ID の実行中にスキャンされるレコードの数が制限に達すると、すべてのサブパーティションのスキャンが途中で終了しますが、小さな ID でクエリを実行する場合、レコードの総数は制限よりも少ないため、パーティション全体をスキャンする必要があります。最適化を行わないと、パフォーマンスの問題が発生します。

解決策:

• 大きい ID と小さい ID の一貫性のないクエリ パフォーマンスの問題を解決するには、idx_gmt_create_id インデックスを再構築し、完全なパーティション スキャンを回避するために feeded_id フィルター列を追加する必要があります。特定のインデックスは、KEY `idx_フィードバック_id_gmt_create_id` (`フィードバック_id`、`gmt_create`、`id`) BLOCK_SIZE 16384 LOCAL です。

• OB 側は逆ソート用に最適化されており、新しいバージョンでは修正されています。

5. 高徳雲原生生態の将来計画

オートナビは、「科学技術の革新を促進し、エコロジーとともに進化する」という当初の目的に沿って、技術革新を通じて現実世界をつなぎ、より良い旅を実現するための生きた地図を構築します。その過程で、技術的手段を使用して製品を効率的に反復してユーザーエクスペリエンスを向上させます。また、技術的手段を使用してコストを削減し、人件費とリソースコストをカバーします。

実は、インターネットの発展の現段階では、「コスト削減」と「効率化」という２つのキーワードも非常に重要です。「モノリシックアーキテクチャ」から「分散アーキテクチャ」、現在の「マイクロサービスアーキテクチャ」、そして将来の「クラウドネイティブアーキテクチャ」へと移行し、データも当初のxGから現在のxPBレベルまで進化しました。ChatGPT の出現により、アルゴリズムも栄光の時代を迎えました。「アルゴリズム + ビッグデータ」アプローチは、人間の脳の思考方法をシミュレートし、人間の効率向上を支援できます。この新しいテクノロジーにより、機械も涅槃を完成させることができます。 、私たちはそれを「シリコンベースの生命」と呼んでいます。

この観点からすると、テクノロジーはイノベーションと社会の進歩を促進することができ、新しいテクノロジーを受け入れることは私たちにとって特に重要です。この生態環境の中でより良いサービスを提供することが私たちの本来の目的であるため、新しい技術を受け入れるだけでなく、社会にフィードバックし、技術革新を促進し、環境の発展を促進する必要があります。それでは、クラウド ネイティブでどのように「コストを削減」し、「効率を向上」させるかについて話しましょう。

OB もクラウドネイティブ データベースであるため、コスト削減とパフォーマンス (AP シナリオをカバー) で大きな進歩を遂げるために、その後のクラウドネイティブ計画において OB と引き続き協力していきます。AutoNavi はサーバーレスで 100 万/QPS+ の実績を達成しました。今後もこの利点を活かし、クラウドネイティブ + 業界独立アーキテクチャを使用して開発効率を向上させます。例えば、サーバーレスを使用することで、研究開発コストの大幅な削減、人的効率の向上、スピードアップが可能になります。」ビジネスを高速化し、究極のユーザー エクスペリエンスを同時に提供します。

[読者は「OceanBase は分散データベースではないのですか? いつからクラウド ネイティブ データベースになったのですか?」という疑問を持つかもしれないので、ここでクラウド ネイティブの概念を確認します。]

クラウドネイティブは実際にはアーキテクチャ上のシステムであり、システムに関しては方法論が導き出されます。クラウドの意味は、アプリケーションとデータがコンピューター室や IDC にあるのではなく、N 台の複数のマシンで構成されるクラウドにあるという意味です。ネイティブ設計は最初からクラウド アーキテクチャに基づいており、リソース プーリング、弾力性などのコア機能を提供します。そして分散型サービス。 

非ネイティブからクラウド ネイティブへの変換パスは次のとおりです。 

1. DevOps のイテレーションと運用とメンテナンスの自動化、柔軟なスケーリング、動的スケジューリング 

2. マイクロサービス、サービスメッシュ、宣言型API 

3. コンテナ化 

4. 継続的デリバリー

OB はテナントの概念を提供し、リソース プール + 弾力性 + スケジューリングがすべて互いに分離されており、データは非常に安全です。OB 自体のコンポーネントもサービス指向の基本サービスであり、コンテナー内で実行することもできます。ネイティブ アーキテクチャに必要な機能を実現し、すべての OB リソースはクラウド上にあります。これらの観点からすると、OB はクラウドネイティブなデータベースです。

5.1 AutoNaviとOceanBaseの連携の今後の展望

以上、OBの技術的な裏話も簡単にご紹介しましたが、結論を直接お話しましょう。DevOps と継続的デリバリーについてはここでは触れません。現在、すべてのデータ ストレージ ツールがこれを実行し、究極のユーザー エクスペリエンスを提供し、運用とメンテナンスが容易になっているからです。ここでお話したいのは、OB のデータ圧縮テクノロジです。OB は、データ圧縮とルーティングにおいて多くの最適化と革新を行ってきました。データ圧縮だけで言えば、ストレージ容量を増やすために、列タイプごとに異なる圧縮テクノロジを提供しています。できるだけ小さくすると、クエリ効率が失われます。

ここで疑問が生じますか? Amap がデータ圧縮とストレージ容量のサイズをそれほど気にするのはなぜですか。実は、この問題をまず考えてみると、Amap を使用する場合、現在使用されている機能は体性感覚機能だけです。より良いユーザー エクスペリエンスを提供するために、ユーザー エクスペリエンスを向上させるために多くのデータとアルゴリズムの作業を行ってきました。その結果、AutoNavi データの量が非常に大きくなり、必要なコストが非常に高くなり、おそらくビジネスの観点から見ると、この領域の最適化はコストを節約するだけでなく、消費電力を削減し、環境を保護することにもつながるため、当社にとって大きなメリットがあります。別の観点から見ると、極限の最適化も私たちの追求です。

要約すると、詳細な計画だけでなく、今後の OB との協力も重要です。事項は次のとおりです。

• AMAP データは大量であるため、今後も OB (通常の構造化バージョンおよび非構造化バージョン) が実装され続ける予定です。

• OB の AP 機能を調べて ADB ソリューションを置き換える

• サーバーレス エディションを探索する

図 5.1 オートナビと OB の今後の連携の見通し

5.1.1 大規模データ プロジェクト - 構造化データ

Amap には、多くの構造化データが Lindorm に保存されています。Lindorm は本質的に列ストレージ + マルチコピー冗長アーキテクチャであり、本質的に OB と同じ高可用性アーキテクチャです。列ストアド データベースは実際にはビッグ データの計算に非常に適しており、Sum を計算するには、列の値を 1 回読み取って計算するだけで済みます (ここでは列の値であり、IO 計算は必要ありません)。構造化データもサポートされていますが、複雑なクエリが含まれるため、結局はあまり適したシナリオではありません。OB への移行の方が適しています。別の観点から見ると、OB のマルチカラム型圧縮はコスト面でも大きなメリットがあります。

今後は、構造化データシナリオのビジネスを（ストレージ）オートナビ（構造化ストレージ）などのOBに移行し、50％以上のコスト削減を目標に進めていきます。

もちろん、移行後も、データを圧縮できるノード数を最小限に抑え、大規模なセールや大量のボリュームが発生した場合には自動的に柔軟な拡張が行われる、OB 線形最適化の利点も享受できます。バランスの問題を解決するために、自動かつ透過的な拡張が完全に実現されています。

 

図 5.2 OB 弾性膨張設計

5.1.2 大規模データ プロジェクト - 非構造化データ

Amap の複雑なシナリオでは、構造化データと多くの非構造化ストレージ シナリオを扱いますが、これは 1 つの Key が 1 つの Val に対応する単純な KV モデルではありません。非構造化シナリオでは動的な列スキーマレス機能が必要であり、固定テーブル構造も混在するため、アプリケーションは実際にはさらに複雑になります。そのため非常に複雑になります。マルチバージョンのデータ保持を追加すると、クエリはより複雑になります。これで終わりだと思いますか？列レベルの TTL も追加します。この複雑な組み合わせにより、データベースの機能とパフォーマンスが実際にテストされます。私たちのニーズを受け取った後、OB は非常に迅速に対応し、私たちをサポートする NoSQL+ マルチバージョン データ バージョンを迅速に開発しました。現在、これでほとんどのシナリオが満たされています。列レベルの TTL はほぼ開発されており、今後数か月以内に安定したバージョンが提供される予定です。

現在、タクシー配車機能プラットフォーム (典型的な KV シナリオ) を OB に移行することを目標として、OB との非構造化データ シナリオを検討しており、推定コスト削減目標は 50% 以上です。

「マルチバージョン、動的列、列レベル TTL」の組み合わせ機能を個別に提案するだけだと、少し複雑に見えるかもしれませんが、実際には悪くありません。各アプリケーションのデータ レベルが 100 テラバイトを超えるストレージと数百のテーブルである場合、読み取りのピーク値は 100 万レベル/秒、書き込みのピーク値は 100,000 レベル/秒になります。こうやって見ると元気が出ませんか？したがって、この分野のコスト削減は依然として非常に大きく、具体的なコスト削減は 30% ～ 40% です。

5.1.3 OB の AP 機能を調査し、ADB ソリューションを置き換える

OB の現在のエンジン機能はすでに AP シナリオをサポートしていますが、OB の現在のパフォーマンスがまだ低いため、AP でカラム ストレージのパフォーマンスを達成することはほとんど不可能です。OBは今年下半期にピュアカラムストレージエンジンを発売する予定で、ルーティングとデータモード（ホットデータとコールドデータ）で多くの最適化が行われ、パフォーマンスが少なくとも3倍向上する予定だ。また、今年下半期には既存の AP シナリオを OB に試験的に導入する予定で、現時点ではコストが 20% 削減されると見込んでいます。

これは OB の OLAP シナリオの厳密なパフォーマンス要件ではありませんが、ビッグデータ分析シナリオでは実際のパフォーマンスに対する高い要件があるため、コストを削減し、効率を向上させて OB の究極のパフォーマンスを絞り出すという考えに基づいています。 - 時間データ分析 迅速な結果が得られる限り、究極のユーザー エクスペリエンスを提供できます。さらに、同じテナント クラスタ内で、OLTP+OLAP デュアル エンジンの利点とメリットを同時に享受でき、コスト削減のメリットは依然として非常に客観的です。

図 5.3 OB の OLAP ソリューション

もちろん、取引シナリオにも OB を導入しますが、複雑な取引シナリオでは、OB も非常に優れたパフォーマンスを発揮します。

 

図 5.4 OB 取引シナリオの探索

5.1.4 サーバーレスバージョンの探索

Amap 自体はサーバーレスで数百万の QPS を達成し、多くの成果を上げています。当社はサーバーレスの導入経験が豊富であり、再度コストを削減するために、サーバーレス版の OB を OB と合わせて導入することも試みます。

• リソースはオンデマンドで使用され、仕様は動的にアップグレードされます。

• リソースはオンデマンドで使用され、基礎となるストレージ容量が拡張されます。

OB はマルチコピーモード + 転送モード + マジョリティモードであるため、拡張時に使用できます。

図 5.5 サーバーレスに関する OB の調査

5.2 クラウドネイティブのサーバーレスで組み立てられた研究開発エコシステムを構築するためのミニマリスト アーキテクチャ

アセンブリの研究開発といっても、これは新しい言葉ではなく、実はこのアーキテクチャモデルは古くから存在していましたが、実装方法は各社異なります。AutoNavi は、私たちにとってデータ フローが「リクエストとレスポンス」という 2 つの主要な属性であるため、アセンブリベースの研究開発に調整を加えました。しかし、事業ポートフォリオの観点から見ると、実際には「インプットとアウトプット」しかありません。アーキテクチャの観点から見ると、よりシンプル、明確、そして柔軟です。

実際には、「入力と出力」を処理し、その後流れ作業にプロセスを配置するだけで済みます。ビジネスプロセス全体とデータフローは非常に明確になります。また、それを公共の特性に応じて共通のコンポーネントにカプセル化します。再利用によりプロセスの効率が大幅に向上し、労働効率が向上し、その後のメンテナンスコストが削減されます。ビジネスのインキュベーションに直面することを心配する必要はなくなり、状況を変えることを敢えてせず、人から機械、そしてビジネスの反復まで、まさに一石三鳥のメリットを実現します。(補助ツールが多数あるため、ここでは詳しく説明しません。後で別のトピックを書くことができます)

AssemblyはアプリケーションだけでなくサーバーレスFaaSでも利用でき、実際に当社のサービスの多くがサーバーレスBaaSモデルに進化しています。アセンブリ モデル全体がサーバーレス エコシステムに深く統合されています。また、当社は当初の志に応え、技術開発を推進するためにサーバーレス エコシステムの構築を継続し、AutoNavi のサーバーレス FaaS のランタイム スキャフォールディングをコミュニティにオープンソース化し、誰もが AutoNavi のサーバーレス実装ソリューションをすぐに複製できるようにしていきます。「貿易、旅行、広告、自動車エコロジー」など複数のシナリオで導入していますので、興味のある方は「サーバーレスシステム構築&AutoNaviネイティブ実践」で検索してみてください。

全体的な抽象化は次のとおりです。

• 組み立てられた研究開発、レゴ コンポーネント、動的なオーケストレーション、迅速な反復により人間の効率が向上し、メンテナンス コストが削減され、ビジネスを迅速に反復できます。

• サーバーレスのエコロジー構築、より豊富な足場とツールが実装され、コストが急速に削減されます。

• ストレージ層はサーバーレスをサポートし、1 つの機能ですべてを無効にすることができ、デバイスとクラウドが統合され、言語に依存しないため、研究開発の敷居が低くなります。

図 5.6 サーバーレスのクライアントとクラウド エンジンの統合探索設計

6. 参考

[1] Alibaba Cloud. PolarDB-X 技術アーキテクチャ [EB/OL]. 2023-07-18[2023-07]. https://help.aliyun.com/document_detail/316639.html

[2] PolarDB-X. PolarDB-X、OceanBase、CockroachDB、TiDB セカンダリ インデックス書き込みパフォーマンス評価 [EB/OL]. 2022[2023-07]. https://www.zhihu.com/org/polardb-x.

[3] Wu L、Yuan L、You J. ビッグ データ アプリケーションのための大規模データ管理システムに関する調査[J]。コンピュータ科学技術ジャーナル、2015、30(1): 163-183。

[4] https://glossary.cncf.io/serverless/

[5] https://developer.salesforce.com/docs

推奨読書

• Amapで自動巡航効果を実現するにはどうすればよいですか?

• アプローチオートナビ 走行ETA（到着予定時刻）

• ARHUDドライビングナビゲーション技術の概要

• AmapがHQ Live MAPを正式リリース

詳細については、「Amap テクノロジー」をフォローしてください