ネットワーク越しのインデキシング速度について

現在、オンプレミス環境にてスタンドアロンのSolrを用いて複数のECサイトを構築しております。これらのシステムを統合し、最新のSolrCloudに置き換えて再構築するにあたり、KandaSearchの使用を検討しております。
現在、Community版を用いて導入検討を行っている段階ですが、一点気になることがございます。
それはインデキシングの速度についてです。ここで言うインデキシングの速度とは、Solrのインデキシング速度(能力)
ではなく、ネットワーク越しのインデキシング速度
についてです。
現在のシステムでは、インデキシングの対象データがSolrと同じイントラネット上に置かれているため、インデキシング速度に問題はございません。しかし、KandaSearchの場合、インターネット越しに自社にある対象データをインデキシングすることとなり、その速度に懸念がございます。
可能であれば、Solrと同じイントラネット上に対象データを一時的に配置し、そのデータに対してインデキシングを行う方法を取りたいと考えておりますが、何か良い方法はございますでしょうか?
または、SolrCloud方式に移行することで、Solrのインデキシング速度(能力)
が飛躍的に向上し、ネットワーク越しのインデキシング速度
が多少遅くても、インデキシング全体の速度を担保できるという理解でよろしいでしょうか?
何卒、よろしくお願い申し上げます。
過去の類似のお問い合わせ
- Solr Docker イメージ
こんにちは、
既存のSolrインスタンスをKubernetesに移行する必要があります。
Dockerfileを作成して
- コアを作成
- データをロード
- Solrを実行
することを試みています。
既存の設定からコアを作成し、以下のコマンドで実行することはできました。
"docker run -v myconf:/myservice solr:6.6 -c myservice -d /myservice"しかし、そのコンテナを新しいイメージに保存し、それをKubernetesで再利用するのは避けたいです。
これは一般的なユースケースだと思いますが、以下のリンクでは何も見つかりませんでした。
https://github.com/docker-solr/docker-solr何か助けになる情報があれば感謝します!
Bjørn Larsen
- Kubernetes SolrCloudクラスタをGitOps方式で構成/再構成する
こんにちは!
スタンドアロンSolrからKubernetes上のSolrCloudセットアップに移行を検討しているとのことですね。Kubernetes環境でConfigSetsやコレクションの管理方法について質問されていますが、確かに一つの解決策として、管理プロセスを導入する方法が考えられます。例えば、bashスクリプトを使用して、ZooKeeperサービスに対してConfigSetsをアップロードし、Solrサービスを経由してコレクションをリロードまたは作成するというアプローチです。このプロセスは、すべてのSolrポッド(およびZooKeeper)が起動して準備が整った後に実行されるべきでしょう。
このようなアプローチで十分機能しますが、他の方法を使用しているかもしれないユーザーもいますので、他の手法についても共有してもらえると参考になるかもしれません。
よろしくお願いします、
Dmitrii Fitisov - CVE-2021-27905は、Apache SolrのReplicationHandler/SSRF脆弱性です。
みなさん、
現在、私たちはアプリケーションでSolr Cloud(Solrバージョン8.6.3)を使用しています。マスター・スレーブのSolrアプローチを使用していないため、私たちのSolrノードのいずれにもレプリケーションハンドラを設定していません。
以下の脆弱性が私たちにも適用可能かどうかを誰か確認していただけますか?CVE-2021-27905 Apache Solr ReplicationHandler/SSRF vulnerability
説明:Apache Solrの8.8.1までのバージョンで重大な脆弱性が見つかりました(CVSS 9.8)。この脆弱性の影響を受けるのは、/replicationファイル内の未知のコードブロックです。masterUrl/leaderUrlの引数を不明な入力で操作すると、特権昇格の脆弱性が発生する可能性があります。 *注:CVE-2021-27905(Apache Solr <= 8.8.1 SSRF)、CVE-2017-12629(SSRF経由のリモートコード実行)、およびCVE-2019-0193(DataImportHandler)を対象としたPOCが今後も登場する予定です。また、Apache Solr Velocity RCE用のMetasploitモジュールと、2つのApache OFBizの脆弱性もあります。脆弱性の数、深刻さ、およびPOCの利用可能性を考慮すると、脆弱なシステムはできるだけ早くパッチを適用することが強くお勧めされます。ありがとうございます
Anchal Sharma - ZooKeeperの障害対応方法
こんにちは皆さん、
私たちはSolr 8.8.2のクラウドセットアップを使用しており、zkアンサンブル3.6.3(3つのzkサーバー)を使用しています。
私たちのHAモニタリングシステムは、solrのURLやシャードの可用性を確認するために5分ごとにpingします。もし問題が発生した場合(solrサーバーがダウンしている場合)、検索をDB検索に切り替えるフラグを立てます。現在、私たちの問題は、zkホストを渡してsolrに接続しているところです。もし2つのZooKeeperがダウンしていて、solrping.process(client)を呼び出した場合、全てのZooKeeperがダウンしているために処理が長時間実行され、スレッドがスタックしてWebLogicアプリケーションサーバーが遅くなっています。
次のようなメソッドがあります:
private int pingRepo(zkHostList, corename) { SolrClient client = SolrConnectionUtil.getSolrClient(zkHostList, “ping”); ((CloudSolrClient) client).setDefaultCollection(corename); SolrPing ping = new SolrPing(); SolrPingResponse resp; try { resp = ping.process(client); return resp.getQTime(); } catch (Exception e) { // Exception handling } return -1; }
この問題をどのように解決すれば良いか、ご提案いただけますでしょうか?ZooKeeperがダウンしている場合の対処方法について、ご意見をお待ちしております。ありがとうございます。
敬具
Reej - /api/cores や /solr/admin/cores がすべてのコアのロードを待ってからのみ返すようにする方法についてはどうすればよいでしょうか?
/api/cores や /solr/admin/cores は、それらが呼び出されたSolrインスタンスのすべてのコアの現在の状態に関する非常に有用な情報を返します。
ただし、Solrインスタンスが再起動したばかりの場合、これらの呼び出しは以下のように空の応答を返すか、または現時点でロードされているコアのみを含んだ応答を返します。すべてのコアがロードされるまで待機させる方法はありますか?
空の応答:
{ "responseHeader": { "status": 0, "QTime": 150 }, "initFailures": {}, "status": {} }
部分的な応答:
{ "responseHeader": { "status": 0, "QTime": 35 }, "initFailures": {}, "status": { "books": { "name": "books", "instanceDir": "/var/lib/solr/books", "dataDir": "/var/lib/solr/books/data/", "config": "solrconfig.xml", "schema": "schema.xml", "startTime": "2022-11-14T20:55:36.571Z", "uptime": 4286, "index": { "numDocs": 0, "maxDoc": 0, "deletedDocs": 0, "indexHeapUsageBytes": 0, "version": 4748, "segmentCount": 0, "current": true, "hasDeletions": false, "directory": "org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/lib/solr/books/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@7bae9d87; maxCacheMB=48.0 maxMergeSizeMB=4.0)", "segmentsFile": "segments_c1", "segmentsFileSizeInBytes": 119, "userData": { "commitCommandVer": "0", "commitTimeMSec": "1658435977333" }, "lastModified": "2022-07-21T20:39:37.333Z", "sizeInBytes": 119, "size": "119 bytes" } } } }
上記の例では、booksコアが空で非常にシンプルなため、他のデータが多いコアよりも比較的速くロードされます。
すべてのコアがロードされた最終的な応答には、私の場合は19個のこのようなコアが含まれます。
トピックへ返信するには、ログインが必要です。