MySQL データの操作もビジネス レイヤーで完了するため、ビジネス レイヤーで他のデータ ソースを同期するのは自然なことです。より一般的なアプローチは ORM を使用することです。関連する同期コードをフックに記述します。
この方法の欠点は、サービスの数が増えると、同期部分が分散しすぎて反復更新が困難になる可能性があることです。たとえば、ES インデックスの互換性のない移行が影響を受ける可能性があります。 。
アプリケーション アーキテクチャがマイクロサービスに進化すると、各サービスは MySQL を直接呼び出すのではなく、ミドルウェア層を介して呼び出すことがあります。他のデータ ソースを同期しながら MySQL を実行します。
この方法にはミドルウェアの適応が必要であり、ある程度複雑です。
MySQL テーブル構造に、updated_at (データ更新時間) などの特別なフィールドを設定します。このフィールドに基づいて、スケジュールされたタスクはクエリを実行します。実際の変更されたデータを使用して、データの増分更新を実現します。
オープン ソースの Logstash を使用して、この方法を完了できます。
もちろん、データの削除操作を同期できないという欠点もあります。
たとえば、有名な運河。
スレーブに扮して MySQL のバイナリ ログを解析し、データの変更について学習します。
これは、業界では比較的成熟したソリューションです。
この方法では、MySQL の binlog-format
を ROW
モードに設定する必要があります。
MySQL の binlog
には 3 つの形式があります:
ROW
モード、binlog はデータ変更を行単位で記録します;
statement
モード、binlog は SQL ステートメントを記録します;
mixed
モードでは、上記の 2 つが混合され、レコードは SQL ステートメントまたは ROW
モードの各行の変更である可能性があります;
場合によっては、MySQL binlog
が ROW
モードに設定されていない可能性があります。この場合でも、binlog を均一に解析して同期を完了できますが、ここではもちろん、解析されるのは元の SQL 文、または ROW
パターンの各行変更です。このとき、これらの SQL または各行変更を、通常のマッチングや AST 抽象構文を使用するなど、業務に応じて解析する必要があります。ツリーなどにアクセスし、解析結果に基づいてデータを同期します。
この方法の限界も明らかです。第一に、ビジネス分析 SQL を適応させる必要があります。第二に、バッチ更新シナリオの処理が難しい場合があります。もちろん、データが単にプライマリに基づいて変更された場合は、キーを削除するか、削除するとより効果的です。
以上がMySQL データを Elasticsearch に同期するにはどのような方法がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。