先週、社内の同僚が MySQL から ES にデータを同期するソリューションについて共有しているのを聞きました。非常に興味深い内容でした。このナレッジ ポイントを要約して改良する必要があると感じ、この記事を作成しました。
この記事では、まず 4 つのデータ同期ソリューションについて説明し、一般的なデータ移行ツールについて説明します。
BB ではなく、記事ディレクトリにあります:
1 はじめに
実際のプロジェクト開発では、読み取りと書き込みの分離を実現し、MySQL データベースのクエリ負荷を軽減し、大量のデータの複雑なクエリに対処するために、ビジネス データベースとして MySQL を使用し、クエリ データベースとして ES を使用することがよくあります。
MySQL データベースと ES 間のデータ同期をどのように実現するかが最も重要な問題の 1 つですが、今日は MySQL と ES 間のデータ同期に関するさまざまな仕組みについて説明します。
以下の 4 つの一般的に使用されるデータ同期スキームを見てみましょう。
2. データ同期方式
2.1 同期二重書き込み
これは、MySQL にデータを書き込みながら ES にデータを書き込む最も簡単な方法です。
アドバンテージ：
シンプルなビジネスロジック。
高いリアルタイム性能。
欠点:
ハードコーディングされているため、MySQL に書き込む必要がある場合は、ES に書き込むコードを追加する必要があります。
強力なビジネス連携。
二重書き込みの失敗によりデータが失われるリスクがあります。
パフォーマンスが悪い MySQL は元々のパフォーマンスがそれほど高くないため、ES を追加すると必然的にシステムのパフォーマンスが低下します。
2.2 非同期二重書き込み
複数のデータ ソースが書き込まれるシナリオでは、MQ を使用して非同期マルチソース書き込みを実装できます。
アドバンテージ：
ハイパフォーマンス;
主に ES ダウンタイムや書き込み失敗などの MQ メッセージの消費保証メカニズムに基づいてデータ損失が起こりにくく、MQ メッセージは再度消費できます。
マルチソース書き込みは互いに分離されているため、より多くのデータソース書き込みを簡単に拡張できます。
欠点:
ハードコーディングされた問題、新しいデータ ソースへのアクセスには新しいコンシューマー コードが必要です。
システムの複雑さが増し、メッセージ ミドルウェアが導入されます。
MQ は非同期消費モデルであるため、ユーザーが書き込んだデータはすぐには表示されず、遅延が発生する可能性があります。
2.3 SQLによる抽出
上記の 2 つの解決策にはハードコードされた問題があり、コードが煩わしすぎるため、リアルタイム要件がそれほど高くない場合は、タイマーを使用してそれに対処することを検討できます。
タイムスタンプ フィールドをデータベースの関連テーブルに追加すると、CURD 操作によってこのフィールドの時間が変更されます。
元のプログラムの CURD 操作は何も変更しません。
タイマー プログラムを追加し、一定の時間に従って指定されたテーブルをスキャンし、その時間内に変更されたデータを抽出します。
ES に 1 つずつ書き込みます。
アドバンテージ：
元のコードへの変更、侵入、ハードコーディングはありません。
強力なビジネス結合はなく、元のプログラムのパフォーマンスは変更されません。
ワーカー コードは簡単に作成でき、追加、削除、変更、確認を考慮する必要がありません。
欠点:
適時性が悪く、タイマーを使用して固定周波数ルックアップテーブルに従ってデータを同期するため、同期周期を第 2 レベルに設定しても、一定の時間遅れが発生します。
データベースには一定のポーリング圧力がかかっています。これを改善する 1 つの方法は、ほとんど圧力をかけずにスレーブ ライブラリにポーリングを適用することです。
古典的なソリューション: Logstash を使用してデータ同期を実現する 基本的な実装原則は、SQL クエリを定期的に使用して、構成に従って新しいデータを ES に書き込み、データの増分同期を実現することです。
2.4 Binlog に基づくリアルタイム同期
上記の 3 つのソリューションには、コード侵入、ハードコーディング、遅延のいずれかが存在します。では、置換侵入なしでリアルタイムのデータ同期を確保できるソリューションはあるのでしょうか?
もちろん、同期には MySQL の Binlog を使用できます。
具体的な手順は次のとおりです。
MySQL の Binlog ログを読み取り、指定したテーブルのログ情報を取得します。
読み取った情報をMQに変換します。
MQ コンシューマ プログラムを作成します。
MQ を継続的に消費し、メッセージが消費されるたびにメッセージを ES に書き込みます。
アドバンテージ：
コードの侵入やハードコーディングはありません。
元のシステムは変更を必要とせず、認識もありません。
ハイパフォーマンス;
ビジネスを分離すると、元のシステムのビジネス ロジックに注意を払う必要がなくなります。
欠点:
Binlog システムの構築は複雑です。
MQ 消費によって解析された Binlog 情報を使用する場合、2 番目の方式と同様に MQ 遅延が発生するリスクもあります。
3. データ移行ツールの選択
上記 4 つのデータ同期方式のうち、現在最もよく使われているのが「Binlog ベースのリアルタイム同期」方式であり、優れたデータ移行ツールも多数誕生していますので、ここではこれらの移行ツールを中心に紹介します。
これらのデータ移行ツールの多くは Binlog サブスクリプションに基づいて実装されており、Binlog ログをサブスクライブする MySQL スレーブをシミュレートして CDC (変更データ キャプチャ) を実装し、送信された変更 (INSERT、DELETE、UPDATE など) をダウンストリームに送信します。 。
どうやって変装するのですか？まず、MySQL のマスター/スレーブ レプリケーションの原理を理解する必要があります。この知識を学ぶ必要がある学生は、以前に書いた高同時実行性のチュートリアルを読んでください。
3.1 チャンネル
データベースの増分ログ解析に基づいて、増分データのサブスクリプションと消費を提供し、現在は主に MySQL をサポートしています。
Canal の原理は、MySQL スレーブ ノードのふりをしてマスター ノードの Binlog ログをサブスクライブすることです。主なプロセスは次のとおりです。
Canal サーバーはダンプ プロトコルを MySQL のマスター ノードに送信します。
ダンプ リクエストを受信した後、MySQL マスター ノードは Binlog ログを Canal サーバーにプッシュし、Binlog オブジェクト (元はバイト ストリーム) を解析して Json 形式に変換します。
Canal クライアントは、TCP プロトコルまたは MQ を通じて Canal サーバーをリッスンし、データを ES に同期します。
以下は Cannel によって実行されるコア プロセスです。Binlog Parser は主に Binlog の抽出、解析、プッシュを担当し、EventSink はデータのフィルタリング、ルーティング、および処理を担当します。
3.2 アリババクラウド DTS
データ転送サービス DTS (データ転送サービス) は、RDBMS、NoSQL、OLAP、およびその他のデータ ソース間のデータ転送をサポートします。
データ移行、リアルタイム データ サブスクリプション、リアルタイム データ同期など、複数のデータ送信方法を提供します。DTS は、サードパーティのデータ ストリーミング ツールと比較して、さまざまな高性能、安全性、信頼性の高い伝送リンクを提供するだけでなく、伝送リンクの作成と管理を大幅に容易にする便利な機能も多数提供します。
特徴：
複数のデータ ソース: RDBMS、NoSQL、OLAP、およびその他のデータ ソース間のデータ送信をサポートします。
複数の送信方法: データ移行、リアルタイム データ サブスクリプション、リアルタイム データ同期などの複数の送信方法をサポートします。
ハイパフォーマンス: 基盤となるレイヤーは、さまざまなパフォーマンス最適化手段を採用しています。完全なデータ移行のピーク時には、パフォーマンスは 70MB/s および 200,000 TPS に達します。各移行または同期リンクが確実にパフォーマンスを維持できるように、高スペックのサーバーが使用されています。良好な伝送性能。
高可用性: 最下層はサービス クラスターです。クラスター内のいずれかのノードがダウンまたは障害が発生した場合、コントロール センターはこのノード上のすべてのタスクを他のノードに迅速に切り替えることができ、リンクの安定性は高くなります。
使いやすさ: 視覚的な管理インターフェイスとウィザード形式のリンク作成プロセスを提供し、ユーザーはコンソールで送信リンクを簡単に作成できます。
手数料がかかります。
DTS のシステム アーキテクチャをもう一度見てください。
高可用性: データ伝送サービスの各モジュールには、システムの高可用性を確保するためのアクティブおよびスタンバイ アーキテクチャがあります。ディザスタリカバリシステムは、各ノードの健全性状態をリアルタイムで検出し、ノードに異常が発見されると、すぐに他のノードにリンクを切り替えます。
データ ソース アドレスの動的適応: データ サブスクリプションおよび同期リンクの場合、災害復旧システムは、データ ソースの接続アドレスの切り替えなどの変更も監視します。データ ソースの接続アドレスが変更されたことが判明すると、動的に適応します。データ ソースが変更された場合に、リンクの安定性を確保するために、データ ソースの新しい接続に接続します。
詳細については、Ali 公式ドキュメントを確認してください: https://help.aliyun.com/product/26590.html
3.3 データバス
Databus は、低遅延、信頼性、トランザクション性、一貫性のあるデータ変更キャプチャ システムです。2013 年に LinkedIn によってオープンソース化されました。
Databus は、データベース ログをマイニングすることで、リアルタイムかつ信頼性の高い方法でデータベースからデータベースの変更を取得します。企業は、カスタマイズされたクライアントを通じて変更をリアルタイムで取得し、他のビジネス ロジックを実行できます。
特徴：
複数のデータ ソース: Databus は、Oracle や MySQL などの複数のデータ ソースからの変更キャプチャをサポートします。
スケーラブルで高可用性: Databus は、高可用性を維持しながら、数千の消費者およびトランザクション データ ソースをサポートするように拡張できます。
順序付けされたトランザクション コミット: Databus は、ソース データベース内のトランザクションの整合性を維持し、トランザクション グループ化とソース コミット順序に従って変更イベントを順番に配信します。
低レイテンシと複数のサブスクリプション メカニズムのサポート: データ ソースの変更が完了すると、Databus はミリ秒以内にトランザクションをコンシューマに送信できます。同時に、消費者は、Databus のサーバー側フィルタリング機能を使用して、必要な特定のデータのみを取得できます。
無制限のバックトラッキング: コンシューマ向けに無限のバックトラッキング機能をサポートします。たとえば、コンシューマがデータの完全なコピーを生成する必要がある場合、データベースに追加の負担を課すことはありません。この機能は、コンシューマのデータがソース データベースより大幅に遅れている場合にも使用できます。
Databus システム アーキテクチャを見てください。
データバスは、リレー、ブートストラップ サービス、クライアント ライブラリなどで構成されます。ブートストラップ サービスには、ブートストラップ プロデューサーとブートストラップ サーバーが含まれます。
変化の速いコンシューマは、Relay からイベントを直接取得します。
コンシューマのデータ更新が大幅に遅れている場合、必要なデータはリレー ログにありませんが、ブートストラップサービスをリクエストする必要があり、返されるデータは、コンシューマが最後に変更を処理してからのすべてのデータ変更のスナップショットになります。
オープンソースのアドレス: https://github.com/linkedin/databus
3.4 その他
かなり
ステートフル コンピューティングの分散処理エンジンと、有界および無界のデータ ストリーム上のフレームワーク。
公式ウェブサイトアドレス：https://flink.apache.org
クラウドカナル
データ同期移行システム、商用製品。
公式サイトアドレス：https://www.clougence.com/?utm_source=wwek
マクスウェル
使い方は簡単で、データの変更を JSON 文字列として直接出力するため、クライアントを作成する必要はありません。
公式ウェブサイトアドレス：http://maxwells-daemon.io
DRD
アリババグループが独自に開発した分散データベースミドルウェア製品は、スタンドアロンリレーショナルデータベースのスケーラビリティ問題の解決に焦点を当てており、軽量（ステートレス）、柔軟性、安定性、高効率という特徴を持っています。
公式アドレス: https://www.aliyun.com/product/drds
ユゴン
ユーザーが Oracle から MySQL へのデータ移行を完了できるように支援します。
アクセスアドレス：https://github.com/alibaba/yugong
4. エピローグ
この記事を通じて、MySQL やその他の多次元データ同期ソリューション、および一般的に使用されるデータ移行ツールについて知っていただき、より良い選択を行えるようにしてください。
したがって、この記事は標準的なテクノロジ選択の記事でもあります。以前、メッセージ キュー、マイクロサービス ゲートウェイ、登録センター、構成センター、およびデータ監視の選択について書きました。この記事は、テクノロジ選択に関する 6 番目の記事として使用できます。
記事を書くことが目的ではなく、どのようにプロジェクトに適用するかが最も重要です現在、専門学校プロジェクトでは MySQL + Cannel + ES のデータ同期ソリューション コードが実装されています 次の記事で説明します具体的な実装ロジックについては、続報をお待ちください。