9

技術者の皆さん、こんにちは。

月に数百万の訪問者がいる（PHP）Webサイトがあり、400万のドキュメントがホストされているWebサイトでSolRインデックスを実行していると仮定します。Solrは4つの別々のサーバーで実行されており、1つのサーバーがマスターで、他の3つのサーバーが複製されます。

5分ごとに何千ものドキュメントをSolrに挿入できます。さらに、ユーザーは自分のアカウントを更新できます。これにより、solrの更新もトリガーされます。

ドキュメントを見逃すことなく、インデックスをすばやく安全に再構築するための安全な戦略を探しています。そして、安全なデルタ/更新戦略を立てること。私は戦略について考えました。ここで専門家と共有して、このアプローチを採用すべきかどうか、または彼らが（まったく）異なるアドバイスをする可能性があるかどうかについての意見を聞きたいと思います。

Solr DataImport

すべての操作で、1つのデータインポートハンドラーを使用します。データとデルタインポートをDataImportHandlerDeltaQueryViaFullImportのような1つの構成ファイルに混合したいと思います。MySQLデータベースをデータソースとして使用しています。

インデックスの再構築

インデックスを再構築するために、私は次のことを念頭に置いています。「ライブ」コアの近くに「reindex」という新しいコアを作成します。dataimporthandlerを使用して、ドキュメントセット全体（400万ドキュメント）を完全に再構築します。これには、合計で約1〜2時間かかります。ライブインデックスには、1分ごとに更新、挿入、削除があります。

約1〜2時間かかった再構築後、新しいインデックスはまだ実際には最新ではありません。遅延を小さくするために、新しいコアに対して1つの「デルタ」インポートを実行して、過去1〜2時間のすべての変更をコミットします。これが行われると、コアスワップを実行します。毎分実行される通常の「デルタ」インポートハンドラーは、この新しいコアを取得します。

ライブコアへの更新のコミット

ライブコアを追跡するために、デルタインポートを毎分実行します。コアスワップにより、インデックスの再作成コア（現在はライブコア）が追跡され、最新の状態に保たれます。dataimport.propertiesもスワップされるので、このインデックスが数分間遅れても、実際には問題にならないはずだと思いますか？デルタインポートはこれらの数分間の遅延を追い越しましたが、可能であるはずです。

あなたが私の状況と私の戦略を理解し、私があなたの目に正しい方法でそれをしているのかどうかアドバイスしてくれることを願っています。また、思いもよらなかったボトルネックがないか知りたいのですが。Solrバージョン1.4を実行しています。

私が持っているいくつかの質問は、レプリケーションについてはどうですか？マスターサーバーがコアを交換する場合、軟膏はこれをどのように処理しますか？

また、スワッピングなどで書類を紛失するリスクはありますか？

前もって感謝します！

4

2 に答える 2

2

良い（そして難しい）質問です！

フルインポートは非​​常に重い操作です。一般に、デルタクエリを実行して、RDMSの最新の変更にのみインデックスを更新することをお勧めします。フルインポートを実行する必要があるときにマスターを交換する理由がわかりました。フルインポートが新しいコアで実行されている間、2時間かかるため、delta-importを使用してライブコアを最新の状態に保ちます。フルインポートがそれほど頻繁に使用されない限り、良さそうです。

レプリケーションに関しては、マスターコアを交換する前に、進行中のレプリケーションがないことを確認します。レプリケーションがどのように機能するかについての詳細は、まだ行っていない場合はSolrwikiを参照してください。

さらに、マスターコアを交換する前に、ライブコアでデルタインポートが実行されていないことを確認します。

于 2012-02-27T11:21:24.220 に答える
1

最後に少し変更された状況があります。2つのDataImportHandlerがあります。1つは完全インポート用、もう1つはデルタインポート用です。デルタインポートは3時間ごとにcronによってトリガーされ、完了するまでに数分かかります。約1,000万のドキュメントの完全なインポートには、約48時間かかります（非常識です！）。すべてのドキュメントのMySQLテーブルから大量のデータがフェッチされるため、これの大部分はネットワーク遅延に関係します。これらの2つのテーブルは2つの異なるMySQLサーバー上にあり、結合できません。

「ライブ」コアがあります。これは、デルタインポートを備えたコアです。別の「再構築」コアを導入し、完了するまでに最大48時間かかる完全なインデックスを実行します。この時点で、「ライブ」コアから更新/削除されたすべてのドキュメントを追跡し、「再構築」コアでデルタインポートを実行して、両方を同じ状態にします。通常、両方のコアが同じ状態になったら、それらを交換して、コアの再構築からサービスを提供します。（再構築コアが完全なインデックス作成を行い、デルタパッチも適用したことを誰が監視しますか？）

場合によっては、「abテスト」のために「ライブ」コアと「再構築」コアの両方を同時に提供したいことがあります。そのような場合、「ライブ」コアと「再構築」コアの両方に一貫性を保つためのデルタインポートがあり、両方が機能します。結果に基づいて、一方を保持し、もう一方を交換して削除したいと思います。

このセットアップ全体を操作上安定させるために、「再構築」コアがインデックスを作成しているか、それを使用して実行されているかを確認するモニタープロセスを導入する予定です。インデックスが作成されている場合、監視プロセスはデルタドキュメントで更新し、両方のコアのデルタインデックスcronをアクティブにします。abフェーズが完了すると、コアの1つがアンロードされ、もう1つのコアが交換されます。その後、余分なcronは無効になります。

この設計にはさらにいくつかの可動部品があり、モニタープロセスの信頼性はスムーズな操作にとって重要です。提案/代替案はありますか？

于 2013-02-28T09:24:39.917 に答える