大手インターネット企業のテクノロジー - elasticsearch(es) - データ量が大きい場合 (数十億レベル) のクエリ効率を向上させます。
目次
3. パフォーマンス最適化の切り札（ファイルシステムキャッシュ）
1. 問題分析
この質問は、はっきり言ってESを実際にやったことがあるかどうかで決まります。実際のところ、ES のパフォーマンスは思っているほど良くありません。データ量が多い場合、特に数億個のデータがある場合、検索の実行に 5 ～ 10 秒かかることに混乱することがありますが、これは詐欺です。初めて検索するときは 5 ～ 10 秒かかりますが、その後は速くなり、おそらく数百ミリ秒程度になります。
非常に混乱しています。どのユーザーの最初のアクセスも遅くなりますが、遅延していますか? es をプレイしたことがない場合、または体験版をプレイしたばかりの場合、この質問をされると簡単に混乱してしまいます。これは、es をプレイするのが本当に苦手であることを示しています。
2. 問題分析
正直に言うと、ES パフォーマンスの最適化に特効薬はありません。パラメーターを調整するだけでパフォーマンスが低下するすべてのシナリオに対処できるとは期待しないでください。おそらく、一部のシナリオではパラメーターを変更したり、構文を調整したりできますが、これはすべてのシナリオに当てはまるわけではありません。
3. パフォーマンス最適化の切り札（ファイルシステムキャッシュ）
es に書き込むデータは、実際にはディスク ファイルに書き込まれます。クエリを実行すると、オペレーティング システムはディスク ファイル内のデータをファイル システム キャッシュに自動的にキャッシュします。
es の検索エンジンは、基盤となるファイル システム キャッシュに大きく依存しています。ファイル システム キャッシュにより多くのメモリを与え、そのメモリにすべての idx セグメント ファイル インデックス データ ファイルを収容できるようにしようとすると、基本的に検索でメモリが使用され、パフォーマンスが低下します。非常に高くなります。
パフォーマンスの差はどれくらい大きくなる可能性がありますか? これまでのテストやストレス テストの多くでは、ディスクを使用した場合、通常は数秒かかり、検索パフォーマンスは間違いなく 2 番目のレベル (1 秒、5 秒、10 秒) でした。しかし、純粋なメモリであるファイルシステム キャッシュを使用する場合、一般的に、パフォーマンスはディスクのパフォーマンスよりも桁違いに高くなります。ディスクのパフォーマンスは、基本的に数ミリ秒から数百ミリ秒の範囲のミリ秒レベルです。
ここに実際のケースがあります。某社のesノードは3台あり、1台あたり64Gとメモリが多いようで、合計64 * 3 = 192Gとなります。各マシンは 32G の ES JVM ヒープを提供するため、ファイルシステム キャッシュ用の残りのメモリはマシンごとに 32G となり、クラスタ内のファイルシステム キャッシュに提供される合計メモリは 32 * 3 = 96G になります。このとき、ディスク全体のインデックスデータファイルは3台のマシンで合計1Tのディスク容量を占有し、esのデータ量は1Tなので、各マシンのデータ量は300Gとなります。これはうまく機能しますか? ファイル システム キャッシュのメモリは 100G しかありません。データの 10 分の 1 をメモリに配置でき、残りはディスク上にあります。検索操作を実行するとき、ほとんどの操作はディスク上で実行され、パフォーマンスは間違いなく悪いです。
最終的には、パフォーマンスを向上させたいと考えますが、最良の場合、マシンのメモリは総データ量の少なくとも半分を収容できます。
運用環境での私たち自身の実際の経験によると、最良の場合、検索に使用するインデックスである es には少量のデータのみが保存されます。ファイルシステム キャッシュに残されたメモリが 100G の場合、インデックス データは 100G 以内に制御され、この場合、ほぼすべてのデータがメモリ内で検索され、パフォーマンスは非常に高く、通常は 1 秒以内です。
たとえば、データ行ができたとします。id、名前、年齢....30フィールド。しかし、今検索する場合は、id、名前、年齢の 3 つのフィールドに基づいて検索するだけで済みます。愚かにもデータ行のすべてのフィールドを es に書き込むと、データの 90% が検索に使用されなくなり、その結果、es マシン上のファイルシステムのキャッシュ領域を占有することになります。単一のデータの量が増えると、ファイルシステムのキャッシュがキャッシュできるデータが少なくなります。実際には、es に取得したいフィールドをいくつか書き込むだけで、たとえば es id、name、age の 3 つのフィールドを書き込むだけで、他のフィールドのデータを mysql/hbase に保存することができます。通常は、es + hbase などのアーキテクチャを使用することをお勧めします。
hbase の特徴は、大規模なデータのオンライン ストレージに適していることです。つまり、大量のデータを hbase に書き込むことができますが、複雑な検索は実行せず、id または range に基づいた単純なクエリを実行するだけです。es で名前と年齢に従って検索すると、得られる結果はわずか 20 個のドキュメント ID である可能性があります。次に、ドキュメント ID に従って、hbase に移動して、各ドキュメント ID に対応する完全なデータをクエリし、それを見つけて、それを返します。フロントエンド。
es に書き込まれるデータは、es のファイルシステム キャッシュのメモリ容量以下、またはわずかに大きいことが望ましいです。次に、es から取得するのに 20 ミリ秒かかり、その後、es から返された ID に基づいて hbase で 20 個のデータをクエリしますが、かかるコストはわずか 30 ミリ秒です。おそらく、以前はこのようにプレイして、1T のデータを es に入れ、クエリ時間は 5 ～ 10 秒ですが、各クエリが 50 ミリ秒になると、パフォーマンスが非常に高くなる可能性があります。
4. データのウォームアップ
上記の計画に従っている場合でも、ES クラスター内の各マシンによって書き込まれるデータの量は依然としてファイルシステム キャッシュの 2 倍を超えているとします。たとえば、60G のデータをマシンに書き込む場合、ファイルシステム キャッシュは 30G になります。 、ディスク上にはまだ 30G のデータが残っています。
実際、データの予熱を行うことができます。
たとえば、Weibo を例に挙げると、通常は多くの人が閲覧する大きな V データ用のバックエンド システムを作成できます。バックエンド システムは時々、ホット データを検索してファイル システムにフラッシュします。キャッシュ、ユーザーが後でホット データを実際に見るときは、メモリから直接検索するため、非常に高速です。
または、電子商取引の場合は、iPhone 8 などの最も閲覧されている製品のホットデータ用のプログラムをバックグラウンドで作成し、1 分ごとにアクティブにアクセスして、ファイルシステムのキャッシュにフラッシュすることができます。
頻繁にアクセスされるホットなデータについては、特別なキャッシュ予熱サブシステムを構築するのが最善です。これは、データがファイルシステムのキャッシュに入るように、ホットなデータに時々事前にアクセスすることを意味します。こうすることで、次に他の人が訪れたときのパフォーマンスがさらに良くなります。
5. 温冷の分離
es は、mysql と同様の水平分割を行うことができます。これは、めったにアクセスされず頻度が非常に低い大量のデータに対して別のインデックスを書き込み、その後、頻繁にアクセスされるホット データに対して別のインデックスを書き込むことを意味します。コールド データを 1 つのインデックスに書き込んでから、ホット データを別のインデックスに書き込むことをお勧めします。これにより、ホット データがウォームアップされた後、それらをファイル システムの OS キャッシュに保持し、コールド データが保存されるのを防ぐことができます。フラッシュ、負け。
6 台のマシン、2 つのインデックス (コールド データ用に 1 つ、ホット データ用に 1 つ) があり、各インデックスに 3 つのシャードがあるとします。3 台のマシンが加熱データ インデックスをリリースし、他の 3 台のマシンが冷却データ インデックスをリリースします。この場合、ホット データ インデックスへのアクセスに多くの時間が費やされ、ホット データが総データ量の 10% を占める可能性があります。この時点では、データ量は非常に少なく、そのほとんどすべてがファイルシステム キャッシュにより、ホット データへのアクセスが保証され、パフォーマンスが非常に高くなります。ただし、コールド データの場合は、別のインデックス内にあり、ホット データ インデックスと同じマシン上にないため、それらの間には接続がありません。誰かがコールド データにアクセスすると、大量のデータがディスク上に存在する可能性があります。現時点では、パフォーマンスが低下します。コールド データにアクセスする人が 10% だけで、コールド データにアクセスする人が 90% であっても問題ありません。ホットなデータ。
6. ドキュメントモデルの設計
MySQL の場合、複雑な関連クエリが存在することがよくあります。es でのプレイ方法? es では複雑な関連クエリを使用しないようにしてください。一度使用すると、パフォーマンスは一般的にあまり良くありません。
最初にJava システムで関連付けを完了し、関連付けられたデータを es に直接書き込むのが最善です。検索する場合、結合などの関連検索を完了するために es の検索構文を使用する必要はありません。
ドキュメント モデルの設計は非常に重要であり、操作がたくさんありますが、検索するときだけさまざまな複雑で煩雑な操作を実行する誘惑に駆られることはありません。es でサポートできる操作は限られているため、操作が簡単ではない操作に es を使用することは検討しないでください。そのような操作がある場合は、ドキュメント モデルの設計および作成時に完了するようにしてください。また、結合/ネスト/親子検索などの複雑すぎる操作は、パフォーマンスが低下するため、できるだけ避ける必要があります。
7. ページングパフォーマンスの最適化
ES のページングは非常に難しいのですが、なぜですか? たとえば、ページごとに 10 個のデータがあり、ページ 100 をクエリする場合、実際には、各シャードに保存されている最初の 1,000 個のデータを調整ノードにクエリすることになります。 5,000 個のデータがあり、調整ノードはこれらの 5,000 個のデータに対してマージと処理を実行し、100 ページの最後の 10 個のデータを取得します。
分散すると、100ページの10個のデータを確認したい場合、5つのシャードからシャードごとに2個のデータを確認し、最終的にコーディネーションノードで10個のデータにマージすることは不可能ですよね。各シャードから 1,000 個のデータを確認し、必要に応じて並べ替えやフィルター処理などを行い、最後に再度ページ分割してデータの 100 ページ目を取得する必要があります。ページをめくるとき、ページをめくるほど各シャードから返されるデータが増え、調整ノードの処理にかかる時間が長くなり、非常にイライラします。そのため、ページングに es を使用すると、後ろに行くほど速度が遅くなることがわかります。
以前にもこの問題に遭遇しましたが、esをページングに使用すると、最初の数ページまでは数十ミリ秒かかりますが、10ページ、数十ページになると、基本的に1ページのデータを見つけるのに5秒から10秒かかります。
8. 解決策
ディープ ページングを許可しない (デフォルトのディープ ページングのパフォーマンスは低い)
あなたのシステムではそれほど深くページをめくることができないことを製品マネージャーに伝えてください。デフォルトでページをめくるほど、パフォーマンスが低下します。
アプリ内でページごとに常にプルダウンされるおすすめ商品と同様です。
Weibo と同様に、下にスクロールしてページを次々と表示することができ、スクロール API を使用して使い方をオンラインで検索することもできます。
スクロールはすべてのデータのスナップショットを一度に生成し、スライドしてページを後方に戻すたびに、カーソルのscroll_idを移動して次のページを取得し、次のページを取得します。パフォーマンスは大幅に向上します。上で述べたページングのパフォーマンスよりも、基本的にはミリ秒レベルで大幅に向上します。
ただし、Weiboのページを下にスクロールしていて、任意のページにジャンプしないようなシーンに適しているということだけです。言い換えれば、最初に 10 ページに移動してから 120 ページに移動し、その後 58 ページに戻ることはできません。自由にジャンプすることはできません。そのため、現在、多くの製品では自由にページをめくることができませんが、アプリや一部の Web サイトでは、下にスクロールしてページごとにめくることができます。
この検索のコンテキストを保存する期間を指定するには、初期化中にスクロール パラメータを指定する必要があります。ユーザーが何時間もスクロールし続けないようにする必要があります。そうしないと、タイムアウトにより失敗する可能性があります。
スクロール API の使用に加えて、search_after も使用できます。search_after のアイデアは、前のページの結果を使用して、次のページのデータを取得することです。明らかに、このメソッドではページをめくることができません。ページは 1 ページのみです。ページを戻してください。初期化中に、一意の値を持つフィールドを並べ替えフィールドとして使用する必要があります。