Elastic Searchハードウェアの推奨事項[終了]

ElasticSearchをサポートするためのハードウェアレベルの優れたガイドはありますか？LuceneまたはSolrの推奨事項は、開始するのに適していますか？私たちはデプロイメントを展開することを検討しています

• 2700万のドキュメント、8 TBのデータ
• 1日あたり30万件のドキュメントを追加

次に、それを約10倍に拡大します。

• 2億7千万のドキュメント、80 TBのデータ
• 300万ドキュメント/日を追加

これは奇妙なユースケースで、クエリは1日あたり数千回に達しますが、Ajaxy webappを快適に使用できるように応答時間を十分に短くする必要があります。

関係する要素はたくさんあるので、一般的なガイドラインはあまりないと思います。

小規模な評価を行う必要があります。おそらく、初期データセットの1/5を使用して、セットアップで予想されるインデックス作成と検索の負荷をスローしたときの動作を確認してください。これにより、データが検索エンジンで実際に消費する容量を確実に理解できます。elasticsearchの場合、ソースjsonを格納しているかどうか、フィールドの分析方法、およびそれらが格納されているかどうかによって異なります。

EC2は、大量のハードウェア支出なしにelasticsearchを評価するための合理的な方法です。

elasticsearchのようなクラスターベースのソフトウェアの場合、クラスターを小さく保つことと大きく保つことの間にはトレードオフがあります。大規模なクラスターは、サーバーを失ったときに、再割り当てが必要なデータが少ないため、優れています。クラスターが小さいほど、消費するエネルギーが少なく、保守が容易になります。

すべてのインデックスが複製されるため、合計インデックスサイズが約300GB x 2の3500万のドキュメントでクラスターを実行します。これと非常に多数の検索をサポートするために、4つのノードがあり、それぞれに24コア、48 GBのRAM、1 TBのストレージがあり、raid10には10Kのディスクがあります。最近、ヘッドスペースを確保するためにディスクサイズを増やしました。

あなたのケースでは、より多くのRAMとより多くのディスクをお勧めします。その検索ボリュームがあれば、CPUのコストを節約できるでしょう。

キャッシュ（使用されているソフトウェアの内部とOSディスクの両方）は十分にウォームアップされないため、実際には検索ボリュームが少ないとパフォーマンスが低下します。

これが役に立てば幸い、ポール