Il y a beaucoup de facteurs qui peuvent entrer en jeu, donc je ne pense pas qu'il y ait beaucoup de directives générales.
Vous devez effectuer une évaluation à plus petite échelle, peut-être avec 1 / 5ème de l'ensemble de données initial pour voir comment les choses se comportent lorsque vous lancez votre charge d'indexation et de recherche attendue lors de la configuration. Cela vous permettra de comprendre combien d'espace vos données consommeront réellement dans le moteur de recherche. Pour elasticsearch, cela dépend si vous stockez le json source et comment les champs sont analysés et s'ils sont stockés.
EC2 peut être un moyen raisonnable d'évaluer elasticsearch sans une grosse dépense de H / W.
Pour les logiciels basés sur des clusters, comme elasticsearch, il y a des compromis entre garder le cluster plus petit et plus grand. Un grand cluster est agréable car lorsque vous perdez un serveur, moins de données doivent être réallouées. Un cluster plus petit consomme moins d'énergie et est plus facile à entretenir.
Nous exécutons un cluster avec 35 millions de documents avec une taille d'index totale d'environ 300 Go x 2, car tous les index sont répliqués. Pour prendre en charge cela et un très grand nombre de recherches, nous avons 4 nœuds, chacun avec 24 cœurs, 48 Go de RAM et 1 To de stockage avec 10 000 disques en raid10. Nous avons récemment augmenté la taille du disque pour nous assurer d'avoir plus d'espace pour la tête.
Pour votre cas, je recommanderais plus de RAM et plus de disque. Vous pouvez probablement économiser de l'argent sur les processeurs avec ce volume de recherche.
Un faible volume de recherche nuit en fait aux performances, car les caches (à la fois internes au s / w utilisé et au disque du système d'exploitation) ne seront pas bien réchauffés.
J'espère que cela vous aide, Paul