Elastic Searchハードウェアの推奨事項
ElasticSearchをサポートするためのハードウェアレベルの優れたガイドはありますか？ LuceneまたはSolrの推奨事項は、開始するのに適していますか？私たちはデプロイメントを展開することを検討しています
- 2700万のドキュメント、8 TBのデータ
- 1日あたり30万件のドキュメントを追加
次に、それを約10倍に拡大して、
- 2億7千万のドキュメント、80 TBのデータ
- 300万ドキュメント/日を追加
これは奇妙なユースケースで、クエリは1日あたり数千回に達しますが、Ajaxy Webアプリでのエクスペリエンスを向上させるには、応答時間を十分に短くする必要があります。
関係する要素はたくさんあるので、一般的なガイドラインはあまりないと思います。
小規模な評価を実施する必要があります。おそらく、初期データセットの1/5を使用して、セットアップで予想されるインデックス作成と検索の負荷をスローしたときの動作を確認してください。これにより、データが検索エンジンで実際に消費する容量を確実に理解できます。 elasticsearchの場合、ソースjsonを格納しているかどうか、フィールドの分析方法、およびそれらが格納されているかどうかによって異なります。
EC2は、大量のハードウェア支出なしにelasticsearchを評価するための合理的な方法です。
Elasticsearchのようなクラスターベースのソフトウェアの場合、クラスターを小さく保つことと大きく保つことの間にはトレードオフがあります。大規模なクラスターは、サーバーを失ったときに再割り当てが必要なデータが少ないため、いいです。クラスターが小さいほど、消費するエネルギーが少なく、保守が容易になります。
すべてのインデックスが複製されるため、合計インデックスサイズが約300GB x 2の3500万のドキュメントでクラスターを実行します。これと非常に多数の検索をサポートするために、4つのノードがあり、それぞれに24コア、48 GBのRAMとraid10の10Kディスクを備えた1TBのストレージがあります。最近、ディスクサイズを増やして、もっとヘッドルームがありました。
あなたのケースでは、より多くのRAMおよびより多くのディスクをお勧めします。おそらく、その検索ボリュームでCPUのコストを節約できるでしょう。
キャッシュ（使用されているs/wの内部とOSディスクの両方）は十分にウォームアップされないため、実際には検索ボリュームが少ないとパフォーマンスが低下します。
これが役に立てば幸い、ポール