シンプルでわかりやすい！ OLTP シナリオにおけるデータ分散設計の原則

[[316065]]

序文

近年、私は分散プロジェクトに取り組んでおり、その多くは OLTP (オンライン トランザクション システム) シナリオにおけるデータ分散アーキテクチャに関するものでした。流行のさなか、私は偶然この分野の設計と実践をいくつか整理しました。長くなりすぎないように、この記事はデザインセクションと技術セクションに分かれています。設計セクションでは、主にデータ分割の理論と方法、およびいくつかの原則と経験に焦点を当てています。技術セクションでは、主に分散データベースとテーブル ミドルウェアの設計と使用方法、および完全な分散データ サービス プラットフォームの構築方法について説明します。

一般的に、分散アーキテクチャを行う場合、アプリケーション層はステートレスであることが多いため（または、DB、キャッシュ、MQ などにデータを転送することで実現される）、分散が容易です。トラフィックの入り口、つまりアプリケーションの前にロード バランサー (Nginx、HAProxy、F5 など) を追加するだけで済みます。これは、大型の単一ボディアーキテクチャでも利用できます。したがって、一般的に言えば、分散アーキテクチャについて話すとき、重要な部分はデータを分散することです。

従来のモノリシック集中型アーキテクチャ

データ分散はアプリケーションほど単純ではありません。各ノードのデータは異なる場合があり、ルーティングの実行、マルチコピーの一貫性の解決、さらにはマルチ書き込みの競合の解決も必要だからです。実装は複雑ですが、データ分散は基本的に、レプリケーションとシャーディングという 2 つの単純なアイデアで構成されています。レプリケーション テクノロジは従来のリレーショナル データベースでも一般的であり、MySQL Replication や Oracle DataGuard などのマスター/スレーブ システムやアクティブ/アクティブ システムに主に使用されます。 Sharding には、データベース内に対応する製品もあります。たとえば、MySQL Fabric や Oracle Sharding などがありますが、レプリケーションと比較すると、これらのデータベース ベンダーに対応するシャーディング ソリューションは一般に広く受け入れられていません。

NewSQL データベースには、多くの場合、シャーディング メカニズムが組み込まれており、レプリケーションの一貫性を確保するために Paxos および Raft アルゴリズムに基づいています。シャーディングと NewSQL ソリューションの比較については、以前の記事「シャーディングと NewSQL データベース」を参照してください。

OLTP シナリオでは、レプリケーションとシャーディングの考え方が従来のリレーショナル データベースに適用されます。さらによく知られている名前が 2 つあります。データベースとテーブルのシャーディングと読み取り/書き込みの分離です。

データベースとテーブルのシャーディングは、元の単一のデータベース テーブルを分割することです。これは、従来のリレーショナル データベースに基づいて分散アーキテクチャの変革を実現する主要な方法です。最初の質問は次のとおりです。

なぜ分割するのですか?いつ分割する必要がありますか?

容量、パフォーマンス、水平拡張、マイクロサービス

単一マシン データベースのストレージ、CPU、メモリ、およびその他のリソースにはすべて、上限ボトルネックがあります。データ量やアクセス量が一定レベルに達すると、パフォーマンスが急激に低下します。つまり、スケールアップによる垂直的な拡大には上限があり、コストがかかるのです。

スケールアウトの水平拡張を実現するには、元のテーブルのデータを複数の物理ライブラリテーブルに分割して保存する必要があります（水平分割）。

さらに、マイクロサービス アーキテクチャの場合、分割されたサービスは異なるシステムに属し、異なるデータベースに対応するため、実際には垂直分割が行われていることになります。

分割方法は何ですか?

1. 垂直分割

垂直分割は、一般的にビジネスを分割する方法に近いです。この方法は、マイクロサービスを実行するときに最もよく使用されます。具体的な分割は、DDD (ドメイン駆動設計) テクノロジまたはビジネス機能に基づいて行われます。一般的に、境界付けられたコンテキストが決定されると、分割ルールはより明確になります。

この方法はアプリケーションへの影響が少なくなります。通常、独立したデータベース (物理マシンの場合もあれば、異なる実際の列だけの場合もあります) の構成のみが必要です。最大で、複数のデータ ソース選択を含むデータ アクセス レイヤーを作成できます。

垂直分割のもう 1 つのシナリオは、ホット データとコールド データが原因で、同じデータ行内の異なる列のアクセス頻度が大きく異なる場合や、Text や Blob などの一部の大きなフィールドが読み取りと書き込みの効率に影響を与える場合です。この場合、これらの列も異なるテーブルに分割されます。この方法は一般的には一般的ではありませんが、パフォーマンスの最適化を行うときによく考慮されます。

垂直分割

垂直分割の利点：

• 分割後は事業内容が明確になり、分割ルールも明確になります。多くの場合、それはシステムや取引に基づいています
• システム間の統合や拡張が容易
• シンプルなデータメンテナンスと低いアーキテクチャの複雑さ

垂直分割のデメリット:

• 一部のビジネステーブルは結合できず、アプリケーション層のインターフェースを通じてのみ解決できます。
• 各事業の制約が異なるため、単一のデータベースパフォーマンスのボトルネックが存在する
• 分散トランザクションのシナリオは頻繁に発生する

垂直セグメンテーションでは、ビジネス分類に応じてテーブルを異なるデータベースに分散するため、一部のビジネス テーブルが大きくなりすぎて、単一データベースの読み取り、書き込み、およびストレージにボトルネックが発生する可能性があります。この場合、問題を解決するには水平方向のセグメンテーションが必要です。

2. 水平分割

水平分割はより技術的であり、テーブルのデータを複数のデータベースとテーブルに分散します。具体的な方法は、データベースのみを分割する方法、テーブルのみを分割する方法、データベースとテーブルを分割する方法に分けられます。たとえば、注文テーブルの場合、データベースのみが分割され (ds1.order、ds2.order...dsk.order)、テーブルのみが分割され (ds.order_0、ds.order_1...ds.order_n)、データベースがテーブルに分割されます (ds1.order_0、ds2.order_1...dsk.order_n)。

水平分割

水平分割の利点:

• 操作データを同じデータベースに分散している場合は、結合やサブクエリなどの複雑な SQL 文をサポートできます。
• 単一データベースのパフォーマンスボトルネックを解決し、水平拡張をサポート
• アプリケーションが分割されていないため、分散データアクセス層がある場合、アプリケーションの変換が少なくなります。

水平分割の欠点:

• 分割ルールとサブライブラリおよびサブテーブルの数は慎重に設計する必要がある。
• 複数のライブラリが関係する場合、分散トランザクションシナリオが発生します。
• データ容量を拡張する場合、データ移行の作業負荷が大きい
• データベース間の結合にはアプリケーションの実装が必要になることが多く、パフォーマンスが低下します。
• データのマージ、集約、ページングなどはデータベースでは直接サポートできません。

データベースにパーティション テーブルがある場合、データベースをパーティション テーブルに分割する必要がありますか?

従来のリレーショナル データベースのパーティション テーブルは基本的に CPU とメモリを共有するため、依然としてスケールアップの問題に直面しており、パーティション テーブルでサポートされるパーティション キーは柔軟性が十分でないことがよくあります。ただし、OceanBase などの一部の新しい NewSQL 分散データベースでは、パーティション化されたテーブルが異なるストレージ ノードに分散されているため、単一マシンのパフォーマンス ボトルネックの問題を回避できます。

分割の具体的な手順

1. 分割方法を決定する

ビジネスの特性に応じて適切な分割方法を選択し、通常は組み合わせて使用​​します。

1) 垂直分割

• シナリオ: フィールド長とアクセス頻度に大きな差があるフィールドテーブル、マイクロサービス
• 注意: 同じトランザクションで操作する必要があるテーブルを分割しないようにしてください。

2) 水平分割

• シナリオ: データ量が多く、単一のテーブルまたは単一のデータベースのパフォーマンスを超えている
• 注: データベース テーブル スキャン トランザクションを含む、データベース間トランザクションと非シャーディング キー操作テーブル シナリオがあるかどうか

2. 分割フィールドを決定する

1) テーブルとフィールドを垂直に分割する

機能モジュールに応じてテーブルを直接分割できます。いくつかの列を分割する場合は、関連する列または冗長な列を追加する必要があります。

2) フィールドを水平に分割する

分割テーブルにシャード キー (主に主キーまたは一意のインデックス) があり、これらの列にシャード情報が含まれていることを確認します。リクエストにシャード情報が含まれていない場合は、グローバル ルーティング テーブルが必要です。

3. 分割ルールを決定する

1) 範囲

日付、シリアルIDなど、一定の規則に従って順番に増加する業務分野に適しています。この方法は、例えば、0～9999->データベース1、10000～19999->データベース2...となります。 20150101-20161231->データベース1、20170101-20171231->データベース2...

この方法は、当然のことながら水平拡張をサポートし、ホットとコールドの分離、アーカイブ、オンデマンド拡張を容易にしますが、負荷が不均衡になりがちです。単一のデータベースへの負荷が高い場合は、データの移行も必要になります。

2) ハッシュ

データの分布は比較的バランスが取れています。通常、ルーティングは mod ライブラリ/テーブルの数によって計算されます。本質的には事前割り当てです。そのため、容量を拡張する際にはデータの移行が必要になります。通常、コンシステントハッシュ法と指数拡張法があります。

3) アプリケーションのカスタマイズ

アプリケーションはルーティング ルールをカスタマイズし、シャード ID に対応するライブラリ テーブル番号を構成します。これは、ルーティング テーブル、構成ファイル、またはその他のカスタム アルゴリズムを通じて実行できます。この方法は最も柔軟で、動的な変更を実装するのが簡単です。

私たちのプロジェクトでは、方法 1、2、3 がすべて使用されます。

4. 分割数を決定する

1) 対象データ量をTと仮定（ビジネス開発ニーズに基づいて推定）

2) 推奨される単一テーブルのデータ量はP（例：MySQLの場合は500万）であり、サブテーブルの数 = T/P

3) 現在の典型的なビジネスシナリオの構成では、単一のデータベースの安定したパフォーマンスを前提とした対応するデータ容量制限L

単一データベースのパフォーマンスは、CPU (80% 以上)、ディスク IO (ディスク使用率が 100% になると iowait が表示され、徐々に増加します)、トランザクション tps の安定性 (tps に大きな変動が発生します) などのシステム指標に基づいてボトルネック状態を判断することで評価できます。

4) サブライブラリの数 = T/L

ライブラリとテーブルの数は、将来の容量拡張と運用および保守の要件に関係します。多すぎても少なすぎてもいけません。上記の計算は主に容量の観点からのものです。実際のシナリオでは、ハードウェアコストの予算やデータのクリーニングおよびアーカイブ戦略などの要素も考慮する必要があります。

分割後に容量を拡張するにはどうすればいいですか?

1. 垂直方向の拡張

垂直分割後、特定のアプリケーションのデータベース負荷が大きすぎる場合は、リソース構成 (CPU、メモリ、PCIE) を増やすことで垂直に拡張できます。

2. 水平展開

水平分割では、データベース サーバーを追加することで容量を拡張できます。この方法ではデータの移行が必要です。一貫性ハッシュが使用される場合、最も近いノードのデータが移行されます。容量が指数関数的に拡張された場合、すべてのノードのデータの半分を移行する必要があります。

一貫性ハッシュ モードでは移行されるデータの量は少なくなりますが、ホット データとコールド データの分散が不均一になりやすくなります。そのため、私たちのプロジェクトでは指数関数的拡張法を採用しています。具体的な方法は、例えばテーブルを128個にあらかじめ分割しておくことです。プロジェクトの開始時には、これらのテーブルは 4 つのデータベース サーバーに均等に分散されます。業務の拡大やデータ量の増加に伴い、容量は 8 つのデータベースに拡張されます。元の 4 つのデータベースのテーブルの半分を新しく追加された 4 つのサーバーに移行し、SQL ルートを変更するだけです。

倍数による拡張：全体のデータ量の増加に対応するため、拡張後の物理マシンの数は元の2倍になります。

単一のデータベースがホット データによって圧迫されている場合は、新しく拡張されたデータベースからデータベースのデータの一部のみを移行することもできます。

単一データベースの拡張: データのスライスの急速な増加に対処するために、独立した物理マシンに拡張します。

分裂後の問題

• 分散トランザクションの導入に関する問題
• データベース間の結合に関する問題
• マルチデータベースマージソートページング問題
• SQL ルーティングと書き換えの問題
• 複数のデータソース管理の問題
• 多次元分割によるデータ集約やクエリなどの運用上の問題

解決：

• 分散トランザクション、ノード間の結合、ソートのシナリオを可能な限り避ける
• データベース分散トランザクションの使用を避け、柔軟なトランザクション サポート (べき等性、反転、信頼性メッセージ、TCC) を提供します。
• アプリケーション層は結合問題を解決する
• 分散データアクセス層を提供する
• サマリーデータベース、セカンダリインデックスデータベース、小さなテーブルブロードキャスト

分散データ アクセス層については、技術セクションで詳しく説明します。

読み取りと書き込みの分離

実際のビジネス シナリオでは、データベースの読み取り頻度と書き込み頻度は異なります。トランザクション フロー テーブルなど、一部のテーブルでは読み取りよりも書き込みが多くなります。注文テーブルなど、読み取りと書き込みの比率がバランスのとれたものもあります。顧客、情報、構成情報テーブルなど、書き込みよりも読み取りが多いテーブルもあります。

データ シャーディングは、単一ポイントのパフォーマンス ボトルネックと水平拡張機能を解決し、書き込み圧力が比較的高いシナリオに適しています。書き込みよりも読み取りが多いシナリオでは、単一のデータベースの容量がニーズを満たすことができる場合、読み取りと書き込みを分離することで、読み取り負荷が高いという問題を解決できます。具体的には、書き込み操作をマスター データベースにルーティングし、読み取り操作を重みやコンピュータ ルームなどに応じてマスター データベースと各スレーブ データベースに分散することができます。

読み取りと書き込みの分離

読み取り/書き込み分離モードでは、いくつか注意すべき点があります。

1) マスタースレーブ遅延。マスター データベースと比較すると、スレーブ データベースからデータを読み取る際に一定の遅延が発生します (通常はミリ秒レベルですが、書き込み負荷が高い場合は秒レベルになることもあります)。したがって、この方法を選択する場合、企業は一定のデータ遅延を許可する必要があります。たとえば、このメソッドは通常、外部クエリ トランザクションに使用されます。

2) 同じトランザクションでは、データの遅延によりダーティ データが読み取られ、トランザクションの一貫性が損なわれる可能性があるため、スレーブ データベースからデータを読み取ることはできません。そのため、マスター データベースからデータを読み取る必要があります。実際の開発では、トランザクションが自動的にコミットされるかどうかに基づいて、データ アクセス層がメイン データベースからの読み取りが必要かどうかを自動的に判断できます。

3) データ遅延の許容度が非常に低いクエリ トランザクションの場合、開発中にメイン データベースからクエリを実行するための別のインターフェイスをカプセル化するか、入力パラメータに「強力な一貫性が必要かどうか」フラグを追加することができます。トランザクションが実装されると、フラグに基づいてメイン データベースまたはスレーブ データベースから読み取るように選択します。

実際のプロジェクトでは、シナリオに応じてデータベースとテーブルのシャーディングと読み取り/書き込みの分離の両方が使用されますが、データベース シャーディング後には読み取り/書き込みの負荷がそれほど大きくならないため、一般に、データベース シャーディング + 読み取り/書き込みの分離などの複雑なソリューションの使用は避けることに注意してください。

原則と経験

データ配信は、ドメインモデリング、シナリオ分割、データアクセス、データ移行・拡張など、多面的な観点から総合的に検討する必要がある体系的なプロジェクトです。実装する前に、全体的な設計を適切に行う必要があります。以下は、当社の設計原則と経験の一部です。

1) シンプルな解決策で問題を解決する。可能であれば分割を避け、配布のために分割しないでください。読み取りと書き込みの分離によって問題を解決できる場合は、データベースとテーブルを分離する必要はありません。

2) シャーディングを行う場合は、適切なシャーディング ルールを選択し (トランザクションの 90% がシャードを越えないようにする)、すべてのシナリオを整理し、実装前に事前に計画を立てる必要があります。

3) データ アクセス層は強力になるように設計する必要がありますが、無分別な乱用を避けるために使用シナリオを明確に定義する必要があります。たとえば、私たちのプロジェクトのデータ アクセス ミドルウェアは分散トランザクション XA をサポートしていますが、一般的には使用は推奨されません。 DDL をサポートしていますが、オンライン トランザクション中に使用することは禁止されています。複数データベースの連鎖トランザクションの送信をサポートしますが、デフォルトでは厳密な単一データベースのトランザクションのみをサポートします。

4) アプリケーション開発仕様を策定し、SQL の使用制限と要件を明確にし、SQL を可能な限りシンプルに保ちます。たとえば、私たちのプロジェクトでは、PC サーバーにデプロイされた MySQL を使用します。スタンドアロンのパフォーマンスは、ミニコンピュータ上の DB2 や Oracle よりもはるかに劣ります。したがって、トリガー、外部キー、および結合は禁止されています。 SQL 操作ではインデックスと分割列を実行する必要があり (データ アクセス層でもこれが検証されます)、主キーは自動増分である必要があります。

5) 柔軟なトランザクションを使用して、データベース間およびシステム間のトランザクションの問題を解決するようにしてください。 MQ 結果整合性を使用できる場合は、Saga または TCC を使用しないでください。