Existem muitos fatores que podem entrar em jogo, então eu não acho que haja muitas diretrizes gerais.
Você deve realizar uma avaliação em 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ê entenda 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 pesquisa elástica sem um grande gasto h / a.
Para software baseado em cluster, como elasticsearch, existem vantagens e desvantagens entre manter o cluster menor versus 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 de índice em torno de 300 GB x 2, pois todos os índices são replicados. Para suportar isso e um número muito grande de pesquisas, temos 4 nós, cada um com 24 núcleos, 48 GB de RAM e 1 TB 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 recomendaria mais RAM e mais disco. Você provavelmente pode economizar dinheiro em CPUs com esse volume de pesquisa.
O baixo volume de pesquisa realmente prejudica o desempenho, pois os caches (internos ao s / w usado e ao disco do SO) não serão aquecidos.
Espero que isso ajude, Paul