Existem muitos fatores que podem entrar em jogo, então não acho que haja muitas diretrizes gerais.
Você deve realizar uma avaliação de escala menor, talvez com 1/5 do conjunto de dados inicial para ver como as coisas se comportam quando você lança a indexação esperada e a carga de pesquisa na configuração. Isso garantirá que você saiba quanto espaço seus dados realmente consumirão no mecanismo de pesquisa. Para elasticsearch, depende se você está armazenando o json de origem e como os campos são analisados e se eles são armazenados.
O EC2 pode ser uma maneira razoável de avaliar a elasticsearch sem um grande gasto em massa.
Para software baseado em cluster, como o elasticsearch, existem compensações entre manter o cluster menor ou maior. Um cluster grande é bom porque quando você perde um servidor, menos dados precisam ser realocados. Um cluster menor consome menos energia e é mais fácil de manter.
Executamos um cluster com 35 milhões de documentos com tamanho total do índice em torno de 300 GB x 2, já que todos os índices são replicados. Para suportar isso e um grande número de buscas, temos 4 nós, cada um com 24 núcleos, 48GB de RAM e 1TB de armazenamento com 10K discos em raid10. Recentemente, aumentamos o tamanho do disco para garantir que tivéssemos mais espaço para a cabeça.
Para o seu caso, eu recomendo mais RAM e mais disco. Você provavelmente pode economizar dinheiro em CPUs com esse volume de pesquisa.
O baixo volume de pesquisas realmente prejudica o desempenho, já que os caches (internos ao s / w usado e ao disco do SO) não serão bem aquecidos.
Espero que isso ajude, Paul