近年、ローカリゼーションの継続的な進歩と分散データベース技術の発展に伴い、元のデータベースの代わりに国内のデータベースを選択する企業が増えています。しかし、基幹データベースの移行は「怖い」IT業務であり、ちょっとした不注意で「データベースを削除して逃亡」するほどの大きな損害を引き起こす可能性がある。

国内のデータベースは主に分散アーキテクチャを採用しており、技術的に大きな違いがあるため、多くの企業はデータベースローカリゼーションアプリケーションの変革の過程で、アーキテクチャの大きな違い、データの非互換性、構文の違い、パフォーマンスなどの問題を含むさまざまな問題に遭遇することがよくあります。データベース移行という悲惨な作業に。

アプリのレトロフィットそれだけです

データベースローカリゼーションアプリケーションの変革は、ビジネスレベルでは変わりません。その本質は、データベース間の差異を解決することです。ローカリゼーションと従来のデータベースの違いは、次の点にすぎません。

アーキテクチャの違い: アーキテクチャ計画の違いがあるため、データモデルを設計する際にはこれらの違いに注意し、データの保存と配布の合理性を可能な限り確保する必要があります。
機能の違い: 構文と関数に違いがあるため、文法エラー、不完全な関数、または一貫性のないデータの問題を避けるために、変換する際にはこれらの違いに注意する必要があります。
パフォーマンスの違い: パフォーマンスにも違いがある可能性があるため、変換中はこれらの違いに注意し、移行されたデータベースシステムが高いパフォーマンスと安定性を備えていることを確認するように努める必要があります。
その他の側面: セキュリティ、スケーラビリティ、保守性など、他の側面にも注意が必要です。

私たちの練習方法

これらの違いに直面して、アプリケーション変革のプロセスでは、変革されたシステムがビジネスニーズを満たし、高いパフォーマンス、安定性、セキュリティを確保できるように、包括的に検討し、対応する調整と最適化を行う必要があります。研究開発管理プロセスを組み合わせ、「3 段階 11 ステップ」ソリューションを採用し、ローカライズされたデータベースの移行とアプリケーションの変革を実現します。

計画と設計: 選択したデータベースの特性に応じて、テーブルタイプ、シャーディングキー、シャーディングアルゴリズムなどを調整してデータベーステーブルの構造を再計画し、最も合理的なモデルを設計します。
コーディングの研究開発: データベースの相違点を調整し、インターフェイスの適応、データ型、構文の互換性、関数の互換性を通じてコードを変換し、ビジネス機能が損なわれないようにします。
パフォーマンスチューニング: データベース最適化モデルと組み合わせて、ドライバー層、ネットワーク層、プロキシ層、ノード層のデータベースと SQL を最適化し、パフォーマンスと信頼性を確保します。

分散データモデルの設計

国内のデータベースは一般に分散アーキテクチャを採用しており、そのデータモデル設計プロセスは、従来の集中型データベースと比較して、断片化設計、分散設計、オブジェクトの最適化と調整が多くなります。データベースに変換を適用するときは、次の 3 つの手順を完了します。

データシャーディング設計

シャーディング設計の前に、まずコンピューティングノード、データノード、グローバルトランザクションの 3 つの層を含む国内データベースアーキテクチャを理解しましょう。また、もう 1 つの非常に重要な概念は、映画内で分散データベースがデータを分散して保存するということです。たとえば、GoldenDB シャードは MySQL インスタンスに保存されます。国内データベースは、データを正しく断片化し、分散データベースアーキテクチャの利点を最大限に活用するという非常に重要な設計に注意を払う必要があります。

シャードキーの選択において、一意性、均一性、および高いデータ関連性という重要な原則を満たすために、次の 3 つのアイデアがあります。

データが均等に分散されるように、より明確な値を持つ列を選択するようにしてください。均一分散の目的はバレル効果を回避することであり、各ホストはピアツーピアで実行されます。
データノード間のデータフローを回避し、パフォーマンスを向上させるために、結合列またはグループ列を選択してください。
中間結果セットのバックフロー CN ノード (計算ノード) と CN ノードの SQL 分割計算を減らすために、パラメーターを含む列を選択するようにしてください。

シャーディングキーを選択した後、シャーディングアルゴリズムを選択する必要があります。さまざまな分散データベースの分割アルゴリズムは、LIST、RANGE、HASH、複合シャーディングなどをサポートしています。分割アルゴリズムの選択は、ビジネスシナリオと密接に関連しています。ほとんどのビジネスシナリオでは、Able が必要です必要に応じて適切な意思決定を行うために、一般的なシナリオをいくつか紹介します。

時間フィールドで分割する場合は、RANGE または LIST を選択するのが最善です。
バッチシナリオの場合、主に範囲クエリとバッチ書き込みのシナリオが含まれます。範囲クエリのパフォーマンスに対する高い要件がある場合は、RANGE を使用できますが、書き込まれる各シャードで不均衡な負荷が発生する可能性があります。バッチ書き込みのパフォーマンスに対する高い要件がある場合は、 HASH を使用しますが、範囲クエリではすべてのシャードが確実にスキャンされるため、パフォーマンスが低下します。

データ分散設計

データベーステーブルの分散設計では、主に、データの冗長割り当てと場所のストライプ割り当てという 2 つの側面を考慮します。

冗長割り当て: 1 つのデータを複数のノードにマッピングします。レプリケーションテーブルとも呼ばれます。テーブルのコピーは、パフォーマンスを向上させるために領域を交換する行為であり、設計時にテーブルの種類、行数、アクセス頻度、関連付けの複雑さを分析することで、アクセス頻度の高いテーブル、構成テーブル、および関連する共通ドライバテーブルをコピーとして設定できます。テーブル。
ストライプ割り当て: 分散データベース内のテーブルの場合は、統一されたシャーディングキーを選択するようにします。つまり、ほとんどのテーブルはこのシャーディングキーに従ってデータを分散できるため、後続のビジネスがデータにアクセスするときに、それらを 1 つの閉ループにまとめることができます。操作はシャード間でのアクセスを伴わずにシャード内で完了します。設計時には、高頻度の SQL と遅い SQL を分析し、テーブルの分析キーを継続的に調整してデータのストライプ分散を実現する必要があります。

オブジェクト最適化設計

分散データベースアーキテクチャのオブジェクトの最適化は主にインデックス設計の調整であり、分散アーキテクチャの線形スケーラビリティの利点を最大限に活用する必要があります。インデックス設計の調整には主に 2 種類があります。

主キーの選択: 多くの集中型データベースは主キーとして自己増分シリアル番号を使用しますが、自己増分パフォーマンスが低く、セキュリティも高くないため、分散アーキテクチャには適していません。MySQL によって自動的に生成される順序付けされた UUID、ビジネスによって生成されるグローバルに一意なキー、またはスノーフレークアルゴリズムなどのオープンソース UUID 生成アルゴリズムなど、グローバルに一意なキーを主キーとして使用することをお勧めします (ただし、時間遡行の問題）。

通常のインデックス設計: インデックスフィールドにはシャードキーが含まれていないことが多いため、インデックスを使用するときにすべてのシャードをクエリする必要があり、パフォーマンスは比較的劣ります。1) インデックスフィールドをシャードキーとして設定し、インデックステーブルを作成して実装する、2) 追加のシャードキー情報をインデックスに追加する、という 2 つの設計を採用できます。

Code Four の互換性の変更

データモデルを調整した後、互換性を確保するためにコードが変更されます。データベースオブジェクトの広範な適応と、相違点と変換ポイントの詳細なマイニングという 2 つの要件があります。まず、幅の広さという点では、コードに含まれるデータベースインターフェイス、データ型、構文、関数の 4 つの側面を、互換性を確保するために包括的に変更する必要があります。

インターフェース適応変換

JAVA アプリケーションは通常、データベースへの接続に JDBC プロトコルを使用しますが、分散データベースの利点を最大限に活用するには、ドライバーの置き換えに加えて、ドライバーの接続と分散データベースの高可用性パラメーターの設定も必要です。以下は、GoldenDB Driver プロトコル属性変換ポイントの変換プロセスで一般的に使用されます。

データ型変換

データ型の変換には、フィールドの型、精度、長さ、および文字セット間の変換が含まれます。これは、多くの成熟したサードパーティツールまたは製造元のツールで実現できるため、ここでは詳細には説明しません。Oracle は文字列の長さをバイト単位で計算し、MySQL (GoldenDB/OB) は文字単位で計算します。UTF8 文字セット、Oracle のデフォルトは UTF8mb3、MySQL (GoldenDB/OB) のデフォルトなど、文字列の長さのアルゴリズムと文字セットの問題に注意してください。 UTF8mb4に。これらの型はすべて長さの変換が必要です。以下は、GoldenDB フィールド型の精度、長さ、および文字セットのサポートです。

文法互換性のある変換

主流の分散データベースは主に PG (openGauss) と MySQL (OB、GoldenDB) を選択するため、Oracle、PG、MySQL の間の構文互換性に関する差異分析を行う必要があります (分散メーカーは互換性の差異を調整し、差異を減らし、この部分は議論の範囲外です)、マップに従って互換性のないアイテムを開発および修正します。3 つの主な違いは次のとおりです。

機能互換性変更

構文の互換性と同様に、メーカーの互換性変更に加えて、Oracle、PG、MySQL の機能差分も変更する必要があり、共通する機能差分は次のとおりです。

なお、フィールドの NULL 値、データベース内の NULL 値は特別な存在であり、データベースごとに多少の違いがある場合があります。たとえば、GoldenDB では、NULL に対して次の制限があります。

NULL フィールドは、グローバルインデックスおよびシャードキーとして使用できません。
NULL はどの値とも等しくありません (TRUE、FALSE、NULL を含む)。関係演算 (より大きい、より小さい、等しい、等しくない) は実行できません。
NULL値はIS NULLかIS NOT NULLかを判定し、NVL関数やNVL2関数などの関数で通常の値に変換できます。
NOT IN サブクエリでは、サブクエリによって返された結果セットに NULL 値が含まれている場合、NOT IN 条件全体が空として返されます。

コードの違いを徹底的に分析した後、違いのある SQL をどのように掘り下げるか? データベースの非互換性を収集するために使用できる再生には 2 つのタイプがあります。

方法 1 : MyBatis プラグインメカニズムを使用してカスタムプラグインを作成し、SQL Prepare ステージにカスタムロジックを挿入して SQL ステートメントを取得および出力し、アプリケーション SQL の記録を実現します。

方法 2 : Oracle の WCR ツールを使用してデータベース実行 SQL を記録するこの方法ではすべての SQL を取得できますが、アプリケーションを特定することはできず、運用と保守や Oracle の内部事情など、アプリケーション以外の SQL を除外するために SQL をフィルタリングする必要があります。

WCR の再生プロセス

最後に、キャプチャした SQL をターゲットライブラリ構文に変換し、再生して互換性のない項目を検出し、R&D とテスターが図に従って変更できるように修正された標準項目を形成します。

データベースの段階的なパフォーマンスの最適化

データベースの最適化を分析する前に、SQL 実行の速度に影響を与える可能性のある関連要因を理解するために、SQL 実行のパスを見てみましょう。

ほとんどの分散データベースの実行パスは、アプリケーション -> ドライバー -> プロキシ -> データノードです。つまり、SQL がアプリケーションから開始され、ドライバーが呼び出され、データノードがプロキシによって解析および分割されて、データノード。データノードは SQL を実行し、結果のフィードバックを集計処理のためにプロキシに送信するか、アプリケーションに直接返します。このプロセスから、SQL の実行速度に影響を与えるいくつかの要素を取得できます。

ドライバーの接続性能。
アプリケーションとプロキシ間のネットワーク送信。
Proxyの集計処理能力。
データノード自体のSQL実行効率。

ドライバー層の最適化

ドライバーはアプリケーションとデータベース間のブリッジおよび接続エントリであり、ドライバーを導入するとき、パラメーターの最適化は無視されることがよくあります。SQL 実行パフォーマンスは、データベース接続、SQL キャッシュ、負荷分散などのドライバーパラメーターを最適化することで改善できます。たとえば、GoldenDB ドライバーは次のパラメーターを通じてパフォーマンスチューニングを実行できます。

ネットワーク層の最適化

アプリケーションとプロキシの間のネットワーク送信も重要な問題であり、ネットワーク自体、データ取得メカニズム、データ結果セットが大きすぎるなどの問題が発生する可能性があります。 GoldenDB 変換では次のようになります。

プロキシ層の最適化

プロキシは主に、データの集約と、各 DN から取得したデータの二次関連付けを担当します。これには、独自の分散関連付け操作、つまり「分散 JOIN」が含まれます。

分散 JOIN にはさまざまな状況があり、主に次の 2 つのカテゴリに分類されます。

プッシュダウンできる JOIN、つまり JOIN 操作はデータノードによって完了し、プロキシ層が JOIN 結果を要約します。この方法は、保存と計算が一緒に行われるため、より効率的です。同じディメンションとコピーされたテーブルの JOIN。

同じディメンションの JOIN

テーブル結合のコピー

プッシュダウンできない JOIN の場合、データノードが単一テーブルクエリを実行し、プロキシが JOIN 操作を完了します。この方法は、Nested Loop Join など、大量のデータ同期を必要とし、非効率的です。

ネストされたループ結合

プロキシ層で SQL をチューニングする場合、主に考慮すべき点は、ネストされたループ結合を避けることです。以下は、私たちがプロジェクトで蓄積した最適化の経験の一部です。

ノード層の最適化

データノードは実際には単一の MySQL または PG インスタンスであり、最適化方法は従来のデータベースとあまり変わらないため、ここでは繰り返しません。

エピローグ

データベースのローカライズは「国内」というラベルだけではなく、「集中型から分散型」というクラウドコンピューティングの発展傾向の表れでもある。この種の技術革新によるビジネスソフトウェアの再構築には、分散アーキテクチャの技術、特性、原則を、データベースローカリゼーションアプリケーションの再構築プロセスにおける計画と設計、コード開発、パフォーマンスの最適化のすべての段階に統合して、最大限に活用する必要があります。分散データベースの利点の説明。このようにして、新しいシステムは従来のデータベースにはない機能を備え、より高いパフォーマンス、安定性、機敏なサポートをビジネスに提供できます。専門チームのサポートがあってこそ、お客様がデータベースのローカライゼーションの波の中で目立つようになり、データベースの移行プロセスで少しでも喜びを享受できるよう支援することができます。

この記事は、「ローカライズされたデータベース変換」の実践者に参考とインスピレーションを提供するために、ローカライズされたデータベース変換の実践に関するちょっとした洞察を提供します。

データベースローカリゼーションアプリケーション変革の実践