2

背景: Apache Solr 4 Cookbookを読み終えたところです。その中で著者は、既存のクラスターに新しいものを追加できないため、シャードのセットアップは賢明に行う必要があると述べています。ただし、これは Solr 4.0 を使用して記述されており、現在は 4.1 を使用しています。これはまだですか？この問題が見つからなかったらいいのにと思います。誰かが別の方法で教えてくれることを願っています。

質問: SolrCloud クラスターでシャードを設定するときに、将来保存するデータの量を知っている必要がありますか? 私はSolandraで遊んで、 elastic searchを読みましたが、正直なところ、私は Solr のファンです (そしてその大規模なコミュニティです!)。私もズーキーパーが好きです。今のところ行き詰まっていますか、それとも回避策/パッチはありますか?

編集:上記の質問が NO の場合、多数の (おそらく 100 以上の) シャードを使用して SolrCloud を構築し、それらを (内部的に) 成長させ、データを成長させながら、それらを 1 つずつ剥がして、より大きく、より高速に配置できますか?より多くのリソースを備えたサーバー？

4

2 に答える 2

6

はい、もちろんできます。同じ ZooKeeper インスタンスを指す新しい Solr サーバーをセットアップする必要があります。ブートストラップ中に、サーバーは zk アンサンブルに接続し、それ自体をクラスター メンバーとして登録します。

登録プロセスが完了すると、サーバーは新しいコアを作成する準備が整います。CoreAdminを使用して、既存のシャードのレプリカを作成できます。また、新しいシャードを作成することもできますが、クラスターを再調整するためのすべてのドキュメント情報が含まれていない可能性があるため、Lucene インデックス形式 (すべてのフィールドが保存されているわけではありません) が原因でバランスが取れていないため、新しくインデックス付けされた/更新されたドキュメントのみが取得されます。このサーバー (これを行うことはお勧めできません)。

SolrCloud をセットアップするときは、ドキュメント数の増加要因を考慮してクラスターを作成する必要があります。そのため、最初に 100 万のドキュメントがあり、1 日あたり 10,000 ドキュメントに成長する場合は、クラスターを 5 つのシャードでセットアップする必要があります。 2 台のマシンの初期セットアップでこのシャードをホストしますが、将来、必要に応じて新しいサーバーをクラスターに追加し、それらのシャードをこの新しいサーバーに移動できます。クラスターが大きくなりすぎないように注意してください。Lucene では、5 つのシャードに分割された単一の 20Gb インデックスがすべてのシャードで 4Gb のインデックスになるわけではありません。すべてのシャードは約 (single_index_size/num_shards)*1.1 かかります (辞書の圧縮のため)。これは、任期の頻度によって変わる場合があります。

最後のチャンスは、新しいサーバーをクラスターに追加し、新しいシャード/レプリカを既存のサーバーに追加する代わりに、新しいシャードを使用して新しい別のコレクションをセットアップし、この新しいコレクションに並行して再インデックス付けすることです。次に、インデックスの再作成プロセスが完了したら、このコレクションと古いコレクションを交換します。

于 2013-02-09T08:33:48.607 に答える
3

この問題の解決策の 1 つは、コレクションを作成するときに「暗黙のルーター」を使用することです。

たとえば、アプリケーションのすべての「監査証跡」データを Solr にインデックス化する必要があるとします。新しいデータは毎日追加されます。おそらく、年ごとにシャードしたいと思うかもしれません。

コレクションの初期設定中に、次のようなことを行うことができます。

admin/collections?
action=CREATE&
name=AuditTrailIndex&
router.name=implicit&
shards=2010,2011,2012,2013,2014&
router.field=year

上記のコマンド: a) 5 つのシャードを作成します - 現在および過去 4 年間の 2010,2011,2012,2013,2014 にそれぞれ 1 つ b) 「年」フィールドの値に基づいて正しいシャードにデータをルーティングします (次のように指定されます)。 router.field)

2014 年 12 月には、CREATESHARD API (コレクション API の一部) を使用して、2015 年の準備として新しいシャードを追加できます。次のようにします。

/admin/collections?
action=CREATESHARD&
shard=2015&
collection=AuditTrailIndex

上記のコマンドは、同じコレクションに新しいシャードを作成します。

2015 年になると、データの「年」フィールドに 2015 年が正しく設定されていると仮定すると、すべてのデータが「2015」シャードに自動的にインデックス付けされます。

2015 年に、(データ保持要件に基づいて) 2010 シャードが必要ないと思われる場合は、いつでも DELETESHARD API を使用してそうすることができます。

/admin/collections?
action=DELETESHARD&
shard=2015&
collection=AuditTrailIndex

PSこのソリューションは、コレクションの作成時に「暗黙のルーター」を使用した場合にのみ機能します。デフォルトの「compositeId ルーター」、つまり numshards パラメータで作成されたコレクションを使用する場合は機能しません。

この機能はまさにゲーム チェンジャーです。ビジネスの増大する需要に基づいてシャードを動的に追加できます。

于 2014-02-22T14:02:01.990 に答える