無誘導でスムーズな移行: 大規模で同時実行性の高いデータベースをローカライズするには?

まず、データベースローカリゼーションの背景について説明しましょう。

1. データベースローカリゼーションの背景

国家戦略上、外部情勢がますます複雑化する中、コア技術は独立制御可能、安全、信頼性、効率性、オープン性が急務であり、もう一つはビジネスであり、ビジネスが急速に発展すると様々な問題が次々と発生します。スタンドアロンデータベースボトルネックに到達する、ビジネス分割、垂直分割、水平分割など、すべて多くの研究開発時間が必要です。

第二に、主流のデータベースアーキテクチャ

まず、現在の主流のデータベースアーキテクチャについて説明します。現在、業界の主流のデータベースアーキテクチャは、Shared-Everything、Shared-Nothing、および Shared-Storage の 3 つのカテゴリに大別されます。

すべてを共有

この種のアーキテクチャは、誰もが知っているかもしれません. これは非常に古典的なアーキテクチャです. ホスト上のすべてのプロセスは、CPU、メモリ、および IO を共有します. いずれかのハードウェアがボトルネックに達した場合、それはデータベースがボトルネックに達したことを意味します.

シェアードナッシング

ここでは、2 つのアーキテクチャをさらに細分化することができます。1 つは、従来のスタンドアロンデータベースから進化したプロキシベースのアーキテクチャです。スタンドアロンデータベースがボトルネックに達すると、プロキシのレイヤーを追加します。これにより、データが分散されます。データのスケーラビリティの問題を解決するために異なるノードに接続する; もう 1 つのシェアードナッシングアーキテクチャは、中国で TiDB や OB のような人気のあるデータベースです。

共有ストレージ

この種のアーキテクチャは業界では Aurora よりも有名で、Ali の PolarDB も中国で比較的人気があります。

まず、Shared-Everything アーキテクチャについて詳しく紹介します。このアーキテクチャは誰もが知っているかもしれません. これは伝統的なスタンドアロンのデータベースアーキテクチャです. データベースがボトルネックに達すると, 通常はさまざまな方法を使用してデータを各セットに分散させます. ローカル容量の上限の問題を解決するためにデータベースの。

多くの企業は、この方法を使用して、アプリケーション層、アクセス層、ゲートウェイ層で同じシャーディングロジックに基づいてデータをセットに統合し、セット内のデータのクローズドループを実現しています。このような一連のアーキテクチャを使用して、多くの興味深いことを行うことができます。たとえば、一部のフルリンクオンラインプレッシャーテストでは、データがセット内で既にクローズされているため、テストセット内でデータプレッシャーテストを実行しても、ライン上の実際のデータが汚染されることはなく、直接実行することもできます。 line グレースケール排水、グレースケール公開などをインターネット上で。

共有ストレージアーキテクチャでは、現在、AWS の Aurora が海外で非常にうまく機能しており、Ali の PolarDB が中国でうまく機能しています。データベースの研究開発に非常に多額の投資を行っていると同時に、非常に強力な基盤に依存する必要があるため、これらのデータベースが最初にリリースされた後、Aurora はこれまでクラウドでの展開のみをサポートしてきました。

シェアードナッシングアーキテクチャは、すでに誰もが知っているものです. 従来のデータベースがボトルネックの進化に達した後、単一のサーバーではパフォーマンスと容量の問題を解決できないため、プロキシのレイヤーを追加し、プロキシ上でさまざまなルートを実行します. このアーキテクチャは遅いです.進化して現在に至ります。中国にはこのアーキテクチャに基づいて進化したデータベースが多数あり、現在モバイルで使用されているデータベースのほとんどは同様のアーキテクチャを使用しています。

このアーキテクチャは、次の 3 つの主なコンポーネントカテゴリに分けることができます。

GTM コンポーネントは、グローバルな調整を担当し、主に、グローバル ID のアクティブな生成、GTE ID のスナップショットなど、分散トランザクションの管理を調整するために使用されます。

プロキシ/計算ノード。最初は、プロキシレイヤーは単にデータルーティングを行うだけかもしれませんが、データベースアーキテクチャ全体の進化に伴い、プロキシレイヤーは、分散トランザクションの最適化、コンピューティングのプッシュダウン、一部の SQL 解析など、ある程度のコンピューティング能力も引き受けます。等

現在、基礎となるストレージノードのほとんどは、二次開発用のオープンソースデータベースに基づいており、より一般的なものは MySQL と PostgreSQL です。そのアーキテクチャの利点は、より成熟していて安定していることです。しかし、その欠点は、変換プロセス全体で、最初のステップでシャードキーを選択し、シャードキーに従ってデータをさまざまなノードに分散する必要があるため、変換プロセス全体が非常に苦痛であることです。ビジネスクレイジー。

Shared-Nothing のもう 1 つのアーキテクチャは、前述の OB と TiDB です。TiDB を例にとると、TiDB は Google の論文に基づいて開発された分散型データベースのセットです。このデータベースは、スケジューリング層 PD、コンピューティングノード TiDB、およびその下にあるストレージノード TiKV の 3 つの層に分かれています。

しかし、TiDBは利用過程で明示的にシャーディングキーを指定する必要がなく、データのシャーディングと分割は基盤となるデータベースで自動的に完結するため、このようなアーキテクチャを採用すれば、変換コストが安くなる可能性があります。比較的低い。

要約すると、上記の 4 つのデータベースアーキテクチャはスケーラビリティの観点から見ることができます.最初の 1 つを除いて、動的な水平展開を達成する方法はありません.実際、変換が完了する限り、後の 3 つは基本的に達成できますデータ層. 水平展開.

一貫性に関しては、最初と最後のタイプは基本的に半同期に依存してノード間の一貫性を確保します。中間の 2 種類のデータベースは一般的に分散型コンセンサスプロトコルを使用しており、現在は Paxio プロトコルと Raft プロトコルが広く使用されています。

次に、データベースローカライゼーションの課題と調査における私たちの実際の経験をいくつか紹介したいと思います。

3. データベースローカリゼーションの課題と調査

ビジネスロジックとデータレイヤーの深い結合は、データベース変換プロセス全体で最も厄介なポイントであるため、さまざまなデータベース移行ソリューションが登場しました。これらは、選択、テスト、同期、変換、グレースケール、オンライン、保証。

1つ目は選択段階で、安定性、効率性、コスト、エコロジーにもっと注意を払います。モデルの選択段階は非常に重要な段階です。モデルが適切に選択されていれば、後のデータベースのローカリゼーション変換のプロセスでコストを大幅に削減できるからです。しかし、データベースの変換を行う場合、技術的な要因に加えて、選択段階で考慮しなければならない非技術的な要因が多数あることが多く、最終的には限られた範囲内で最適なソリューションを選択することしかできません。機種選定の段階で、データベース全体のローカリゼーションの問題をすべて解決することは期待できません。

データベースを取得した後、基本的な機能テスト、ユーザビリティテスト、保守性テスト、いくつかの基本的なパフォーマンステストなど、さまざまなテストを行うことがあります。しかし、このようなテストを行った後でも、このデータベースセットがビジネスのニーズを満たすことができるとは保証できません。基本的に要件を満たすことができるデータベースを除外したい場合は、オンライントラフィックの記録とトラフィックの再生を組み合わせる必要がある場合もあります。

データの同期はここで少し拡張できます. この部分は主に完全なデータの同期と増分データの同期に分けられます. この種の大規模なデータの移行を行う場合は、完全なバックアップを検討するのではなく、使用することを強くお勧めします.物理バックアップまたは論理バックアップ、どのツールが強力でどのツールが悪いか。最初のステップは、自分のビジネスを分析し、自分のデータベーステーブルを分析し、ビジネスロジックとは何か、データがどのように分散されているか、過去のデータ、ホットデータ、コールドデータ、および現在使用できるデータを分析することです。すぐに移行する必要があり、後で移行できるデータはどれか... このようなデータ分析の後、完全なデータ移行と増分データ移行を行うと、多くの場合、半分の労力で 2 倍の結果が得られます。

増分同期に関しては、同様の増分データ同期ツールも社内で開発しました。データベース変更のログをリッスンし、これらの変更をミドルウェアを介して Kafka などのメッセージミドルウェアに書き込み、ミドルウェアからビジネスニーズにサブスクライブします。

このようなツールを使用すると、多くの興味深いことができます。前述のデータ移行と同様に、これらのツールを使用して異種データを同期できます。また、キャッシュとしてのデータベース間の同期、OLTP と OlAP 間の同期なども実行できます。このツールは、多くのビジネス上の問題点を解決できます。

ビジネスの変革も非常に痛いポイントです。私たちの変革の重要なポイントは主に 2 つの部分に分けられます。1 つはアプリケーションであり、アプリケーション部分はいくつかのドライバー、構文の互換性、データオブジェクトなど、API、SQL などに重点を置いています。データベースレイヤーは、データシャーディング、ホットとコールドの分離、軽度と重度の分離、SQL の最適化、読み書きの分離などに重点を置いています。

今回の変革で積み上げてきたこの適応と変革には、すでに何十もの注意すべき点があるので、ここでは詳しく列挙しませんでしたが、少しまとめただけです。前のページで述べたのは、データベースのローカリゼーションの変革における最大の問題点は、ビジネスロジックとデータベースの深い結合であるため、この問題は解決できるということです。そのため、変換プロセス中にDBを徐々に単純なストレージに弱体化させ、アプリケーションとデータの境界を明確にしてから、さまざまな適応と変換を行いました。

この一連の操作によるデータベースのローカリゼーションは、アーキテクチャ全体のソートと最適化の役割も果たします。ここでは、スイッチング方式について簡単に説明します。2 つの主なスイッチング方式があり、どちらも現在使用されています。1 つ目は比較的単純なデータ層のミドルウェアに基づくもので、もう 1 つはアプリケーションに基づくものです。この方式は比較的複雑かもしれませんが、この種の安定性とセキュリティの要件は、安定性と要件をより適切に保証します。

データ層に基づくスイッチングについて簡単に紹介します. 最初はアプリケーションがDBに直接接続されている可能性があり、途中でいくつかのVIPのものがあるので、直接省略します. 最初に、ミドルウェアの層を第 1 段階から第 2 段階に追加しました。これは、ミドルウェアも私たちの DB を指しているため、R&D をゆっくりと変更できるためです。変革プロセスに 10 日と半月かかることは問題ではなく、ビジネスに影響を与えることはありません。すべてのトラフィックをミドルウェアに切り替えた後、データベースレベルでパケットをキャプチャして、すべてのリクエストがミドルウェアを通過するようにします。

アプリケーションのすべての変換が完了したら、すべてのデータを新しいデータベースに同期し、読み取りトラフィックを新しいデータベースに置くことができます。アプリケーションはミドルウェアを経由しているため、アプリケーションに対して完全に透過的なミドルウェアで読み取りと書き込みの分離を行います。

読み取りトラフィックを新しいデータベースに送信して、新しいデータベースがビジネス要件を満たすことができるかどうかを確認します. もちろん、そのようなアーキテクチャを介して書き込みトラフィックを確認する方法はありません. 切り替えプロセス中のビジネスへの影響は、わずかコンマ数秒のフラッシュの切断です. 交換後、データを同期します. 問題が発生した場合でも、元に戻す方法があります.

The second solution is the business double-write solution. このソリューションは、前のソリューションよりも安全かもしれませんが、より複雑でもあります。まず、新しいデータベースのセットを準備し、最初に完全同期を実行し、次に増分同期を実行して、両側のデータが等しいことを確認します。次に、別の時間枠を見つけます. もちろん、前提として、前のステップの実行が完了している、つまり、アプリケーションのアダプターカード写真が実行されており、アプリケーションを介して二重書き込みを有効にしてから、両側のデータが書き込まれていることを確認します. 一貫性, この時点で、増分同期を停止し、下部でスクリプトを開始して、両側のデータを非同期的に比較し、両側のデータが一貫していることを確認します.

調整プロセス中に矛盾が見つかった場合は、それらをログアウトし、手動で分析します。両者が一致したら、分析を開始できます。現時点では、旧図書館が中心で、新図書館で補う形で業務を行っているため、現在、新図書館は読み書きの両方を備えており、時間も含め、新図書館のさまざまなソリューション指標をビジネスの観点から見ることができます。新しいライブラリに問題がある場合は、基本的にこの段階で発見でき、ビジネスに影響はありません。十分に安定したら、二重書き込みを元に戻し、新しいライブラリを主ライブラリとし、古いライブラリを補助ライブラリとして、しばらく安定して実行し続けます。新しいライブラリが十分に安定していることがわかったら、二重書き込みを削除します。

上記のステップが完了したら、オンライン化後の保証段階の時間です。ここで行うべきことは主に 2 つあり、1 つは可観測性、もう 1 つは制御可能性と可観測性であり、これにより、障害が発生したときに迅速に検出して特定できるようになります。

可観測性は、ロギング、トレース、およびメトリックの一部であり、誰もがよく耳にするので、詳細には触れません。実際に、基盤となるリソースの監視、ビジネス層の監視、ログ収集プラットフォーム、呼び出しリンク分析プラットフォームなど、先ほどのポイントに対応する構築も行っています。実際、復旧に関しては、過去の障害から障害であることが判明した場合、障害復旧時間のほとんどは障害を修復する瞬間に費やされるのではなく、情報間の分担に費やされます。コミュニケーション担当者障害の発生から対応者との調整、手紙に対応する情報の同期、そして何をすべきかの決定まで。

時間配分のための緊急対応システムを一式作りました。障害を軽微な問題、中程度の問題、重大な問題に分けて緊急時対応計画管理プラットフォームを作成します. 通常、O&M はその上にアトミックな緊急時対応計画の一部を確立するだけでよい場合があります. たとえば、SQL kill、データベースのマスターとスレーブの切り替えなどのアトミックな機能です。次に、非常に成熟したさまざまなアトミック機能をコンティンジェンシープランプラットフォームに統合し、コンティンジェンシープランプラットフォーム上でさまざまな障害コンティンジェンシープランを配置し、AI と組み合わせて、障害が発生したときにコンティンジェンシープランを自動的に推奨し、人間の判断によって補完します。

このようなインテリジェントな計画をモバイル端末にプッシュすることで、ユーザーがモバイル端末をクリックするだけで、計画を自動的に実行できるようになります。たとえば、変換プロセスで発生した比較的単純な問題に遭遇した場合、ダウングレード操作を実行します. ダウングレードには、ビジネスのダウングレード、リクエストのダウングレード、および基盤となるリソースのダウングレードが含まれます. 技術レベルでは、アーキテクチャのダウングレードも行う場合があります.

最後に、まだボトムアップの計画があります. 上記のスイッチングソリューションの中で、それが二重書き込みソリューションであろうと、データベースミドルウェアスイッチングに基づくソリューションであろうと、数秒以内にそのデータベースをロールバックできることを保証できます。二重書き込みスキームのように、構成アイテムに格納されたスイッチとしてその二重書き込みを使用するため、ミドルウェアスキームのように、データベーススイッチのスイッチを変更するだけでフォールバックを作成できます。バックエンド方向。

最後に、データベースローカリゼーションの変革における私たちの経験をまとめます。

要約する

1つ目は、適していることです。実際、ほとんどの場合、集中型データベースがまだ現在の最適なソリューションです. データが数百G、または2または3Tしかない場合でも、集中型データベースが現時点で最良の選択である可能性があります.データのシャーディングを負担する必要はありませんし、さまざまな時間のかかるクロスノード同期など、一連の問題があります。

2 つ目は、特効薬はありませんが、 1 つのデータベースを使用してすべての問題を解決できると期待しないことです。過去にオラクルを使用していたとき、オラクルは引き受ける必要のない多くのことを引き受けました。現在、データベースの変革の過程にあり、そのような問題も徐々に解決しています. たとえば、Redisを使用してアドホッククエリなどの量を処理し、クリックハウスなどのデータベースを使用してそれを実行し、次にそのようなことのいくつかの大規模なレポートの分析を行います。おそらく、同期ツールを介してビッグデータプラットフォームと同期し、ビッグデータプラットフォームを介してこのような分析を行うことになるでしょう。

3つ目は、運用・保守の壁を取り払い、技術やビジネスの壁を打ち破ることです。テクノロジーはビジネスに貢献し、ビジネスと統合することしかできませんが、運用と保守は半分の労力で2倍の結果しか得られず、独自の枠を飛び越えてグローバルな視点から問題を見て初めて、実際の技術運用と呼ばれます。 .