mysqlデータ一括同期インポートelasticsearch

背景:
データのリスト抽出応答が遅くなるには、mysqlからesにデータを移行し、esからデータを読み出す必要があります.
解決方法:
データ量が大きすぎるため、mysqlからesにデータクエリーをインポートするバッチごとに必要です.
シナリオ1:
mysqlからoffset、limitに基づいてページング
シナリオ2:
シナリオ1はテスト中にoffsetが大きいほど、クエリーの時間が長くなるため、テストライブラリで50万件に達するには1 sの時間しかかかりません.esを使用する過程で、esクエリがsearch afterを使用できることを知ったため、mysqlがこのように使用してもクエリの効率を高めることができますか?
このシナリオを使用すると、クエリの効率が大幅に向上します.
シナリオの説明:
シナリオ1:
mysqlからoffset、limitに基づいてページング

select
       id,user_age,user_name
       from message_test
       ORDER BY id
   limit #{offset} , #{limit}

自己測定環境開始時刻14:22:08.786-->14:22:08.845 59 msかかりました

2019-09-12 14:22:08.786 [http-nio-7012-exec-10] DEBUG c.y.s.m.d.M.selectMysqlToES - ==>  Preparing: select id,user_age,user_name from message_test ORDER BY id limit ? , ? 
2019-09-12 14:22:08.786 [http-nio-7012-exec-10] DEBUG c.y.s.m.d.M.selectMysqlToES - ==> Parameters: 0(Long), 1000(Long)
2019-09-12 14:22:08.845 [http-nio-7012-exec-10] DEBUG c.y.s.m.d.M.selectMysqlToES - <==      Total: 1000

80万データの時間になると、14:32:42.2027->14:32:43.464に1437 msの時間がかかったことがわかります

2019-09-12 14:32:42.027 [http-nio-7012-exec-10] DEBUG c.y.s.m.d.M.selectMysqlToES - ==>  Preparing: select id,user_age,user_name from message_test ORDER BY id limit ? , ? 
2019-09-12 14:32:42.027 [http-nio-7012-exec-10] DEBUG c.y.s.m.d.M.selectMysqlToES - ==> Parameters: 816000(Long), 1000(Long)
2019-09-12 14:32:43.464 [http-nio-7012-exec-10] DEBUG c.y.s.m.d.M.selectMysqlToES - <==      Total: 556

全体の流れの下で、81万本のデータを同期して、mysqlから81万本のデータを照会して、それからesに挿入して、全部で10 min 34 s 678 msかかりました

2019-09-12 14:22:08.786       
2019-09-12 14:32:43.464        

シナリオ2:
シナリオがテスト中にoffsetが大きいほど、クエリーの時間が長くなり、データ量が大きいほど、プロセス全体に多くの時間がかかります.esの使用中に、esはsearch after、 mysql search after をサポートし、クエリー効率を向上させることが分かった.

select
       id,user_age,user_name
       from message_test
       WHERE id > #{id}
       ORDER BY id
             limit #{limit}

最初のクエリは14:42:37.71-->14:42:37.109で38 msかかりました

14:42:37.071 [main] DEBUG c.y.s.m.d.M.selectMysqlToESSearchAfter - ==>  Preparing: select id,user_age,user_name from message_test WHERE id > ? ORDER BY id limit ? 
14:42:37.071 [main] DEBUG c.y.s.m.d.M.selectMysqlToESSearchAfter - ==> Parameters: 0(Long), 1000(Long)
14:42:37.109 [main] DEBUG c.y.s.m.d.M.selectMysqlToESSearchAfter - <==      Total: 1000

最後のクエリの場合14:44:30.645-->14:44:30.651以降のデータのクエリは影響を受けないことがわかります

14:44:30.645 [main] DEBUG c.y.s.m.d.M.selectMysqlToESSearchAfter - ==>  Preparing: select id,user_age,user_name from message_test WHERE id > ? ORDER BY id limit ? 
14:44:30.645 [main] DEBUG c.y.s.m.d.M.selectMysqlToESSearchAfter - ==> Parameters: 3061952(Long), 1000(Long)
14:44:30.651 [main] DEBUG c.y.s.m.d.M.selectMysqlToESSearchAfter - <==      Total: 426

合計時間、81万件のデータを照会し、esに挿入し、合計時間は1分53 sかかりました.

14:42:37.071
14:44:30.651

このシナリオを使用すると、クエリの効率が大幅に向上します.
まとめ:
elasticsearchの設計を参照すると、効率を向上させ、不要なオーバーヘッドを節約することができます.今後、いくつかのミドルウェアと業務コードを設計する過程で、他のミドルウェアの良い技術案を参考にして、自分の設計システム設計に運用することができます.