背景
今やデータが王様の時代において、データ量の急速な増加とユーザー規模の拡大に伴い、企業や組織はかつてないほどのデータストレージおよび処理に関する課題に直面しています。シャーディング技術は、データを水平方向に分割する効果的な戦略として、現代のデータベースアーキテクチャ設計における重要な構成要素となっています。 シャーディング技術は、データを複数のデータベースインスタンスまたはテーブルに分散することで、データ処理能力とクエリパフォーマンスを向上させます。この技術は、大規模データ処理、高同時アクセス、複雑なデータモデル管理などのシナリオにおいて特に重要です。単一データベースのパフォーマンスボトルネックを効果的に緩和するだけでなく、システム全体の可用性とフォールトトレランスも向上させます。 金融やインターネット業界では、コアシステムは通常ユニットアーキテクチャを採用しており、シャーディングは非常に一般的です。シャーディングはビジネス上の課題を解決できますが、大量のシャーディングデータベース・テーブルを管理する方法も、DBAや開発者にとって悩みの種となっています。ODCによるシャーディングサポートは、ユーザーのシャーディング管理負担を軽減するだけでなく、今後シャーディングデータベース・テーブルをOceanBaseクラスタにアーカイブするための基盤を築きます。
シナリオの概要
シャーディングは、ビジネス上以下のような課題に直面する可能性があります：
ロジックテーブルの構造変更時に、各シャードに対して同じ変更を行う必要がある。
ビジネスでテーブル構造に変更がある場合、DBAは各シャードに対してDDLを1回ずつ実行する必要があり、作業量が倍増し、プロセスが複雑でエラーが発生しやすいです。
シャーディングルールが複雑で、各ビジネステーブルのデータベース数、シャード数、物理トポロジーを人が覚えておく必要がある。
業務ごとにシャーディングルールが異なる場合があります。ユーザーIDに基づくハッシュモジュロ演算で分割する場合もあれば、日付に基づいて分割する場合もあります。統一された管理プラットフォームがなければ、基本的にメンテナンスは不可能です。
新しいシャーディングを作成する際、事前に計画されたトポロジーに従って、N個のDDLを書いて作成する必要があり、エラーが発生しやすい。
新しいビジネスが立ち上がる際、ビジネス要件に基づいてトポロジーを計画し、シャードを作成する必要があります。一部のビジネスでは、百のデータベースと百のテーブルが必要になる場合があります。その際、DBAは人手で百枚のテーブルを作成する必要があり、自らShellスクリプトを書いてDDLを生成するか、PLを書いて実装する必要があります。どちらの方法でも、メンテナンスが困難で、エラーが発生しやすいです。
シャード間でテーブル構造が一致しない場合、ビジネスに影響を与える可能性がある。
もう一つの厄介な問題は、シャード間でテーブル構造が一致しない場合、ビジネスに影響を与える可能性があることです。構造が一致しないシャードをいかに迅速に検出するかも、DBAにとって悩みの種の一つです。人手によるチェックでは、基本的に非現実的です。
これらシャーディングの課題に対応するため、ODC V4.3.2ではロジックデータベース機能がリリースされ、多様な実行可能な操作を提供し、これらの問題を効果的に解決します。
シャーディングの自動抽出
システム内に既に大量のシャーディングデータベース・テーブルが存在する場合、ODC上でワンクリックでの識別と管理を実現でき、煩雑な再設定を繰り返す必要はありません。
前提条件
- プロジェクトには2つの物理データベース odc_0 と odc_1 が存在します。
- odc_0 には3つのシャードがあります：test_0、test_2、test_4。
- odc_1 には3つのシャードがあります：test_6、test_8、test_10。
- すべてのテーブルの構造は一致しています。
効果の表示：
ご覧のように、簡単な2ステップで、ODCはそのロジックテーブルを自動的に識別し、ロジックテーブルのトポロジー表現 odc_[0-1].test_[0-10:2] を提供します。ここで、odc_[0-1] はシャードが odc_0 と odc_1 の2つのデータベースに均等に分散していることを示し、test_[0-10:2] はシャードの番号部分が0を下限、10を上限、2をステップ幅として増加していることを示しています。すなわち、2、4、6、8、10です。同時に、ロジックテーブルを展開して、各物理データベース下のシャードとシャードの表現を確認することもできます。
各種トポロジーのシャーディングを迅速に新規作成する
論理テーブルは物理テーブルと同じように扱えます。SQLウィンドウで論理テーブルのスキーマを確認することができるだけでなく、物理テーブルを作成するのと同じ方法で論理テーブルを作成できます。
前提条件
論理データベースの設定が完了していること。
効果の例：
論理テーブルの作成
タスク結果の確認
ご覧のように、通常の物理テーブルを作成する場合と唯一異なる点は、論理テーブルのトポロジー分布を決定するために、その論理テーブルの論理テーブル式を指定する必要があることです。ODCはさまざまなタイプのシャーディングトポロジー式をサポートしており、論理テーブルを柔軟に作成できます。詳細な論理テーブル式の構文については、「論理テーブル式」をご参照ください。
論理テーブルスキーマの一貫性検査
一部の物理シャードが何らかの理由でスキーマが不整合になった場合、DBAはどのように迅速に発見できるでしょうか？ODCは、バックグラウンドで定期的に論理テーブルのスキーマを巡回検査する機能を提供しており、手動でのスキーマ一貫性チェックもサポートしています。
前提条件
- t1時点で、odc_test_0、odc_test_1、odc_test_2、odc_test_3のテーブルスキーマは一致しており、1つの論理テーブルとして認識されている。
- t2時点で、odc_test_0のテーブルスキーマに変更が生じる：新しい列c2が追加される。
- t3時点で、論理テーブルのスキーマチェックをクリックする。
効果の例：
スマートグループ化に基づく構造変更
論理テーブルのスキーマを変更する必要がある場合、物理データベースの変更と同様に、論理データベースの変更チケットを発行するだけで済みます。ODCは、論理テーブルの物理トポロジーに基づいて、すべての物理シャードに対して自動的に変更を適用します。ODCの実行ロジックは以下のとおりです：複数の論理SQL間は直列実行し、同一の論理SQL内ではスマート並列実行します。MySQLの場合、物理テーブルが属するデータソースホストに基づいてグループ化し、グループ内は直列、グループ間は並列で実行します。OceanBaseの場合、物理テーブルが属するクラスタに基づいてグループ化し、グループ内は直列、グループ間は並列で実行します。これにより、データベースへの負荷を可能な限り軽減しつつ、同一時刻における物理シャードのスキーマの一貫性を最大限に保証します。
前提条件
既に論理テーブルtestが存在します。
効果の例：
論理テーブル変更タスクの作成
論理テーブル変更タスクの確認
変更の緊急対応と異常回復
データベースの論理ライブラリ変更プロセスにおいて、物理ライブラリのテーブル構造が一貫していることを保証することが重要です。変更ステートメントがすべて正常な場合、処理フローは非常にシンプルです。しかし、一部の物理ライブラリで変更が失敗した場合、迅速に緊急対応を行い、個々の物理ライブラリの問題を手動で解決して論理ライブラリの全体的な変更を継続できる必要があります。実行中のSQLについて、ODCはSQLの終了をサポートします。実行失敗したSQLについては、ODCは全体のタスクを一時停止し、手動処理またはクリックによる無視を待ってから、タスクを再開します。これら2つの機能により、論理ライブラリ変更時の迅速な緊急対応が可能になります。
前提条件
論理テーブルtestには既にc2列が存在します。
効果の表示：
