Hay muchos factores que pueden entrar en juego, así que no creo que haya muchas pautas generales.
Debería realizar una evaluación a menor escala, tal vez con 1/5 del conjunto de datos inicial para ver cómo se comportan las cosas cuando arroja su indexación esperada y la carga de búsqueda en la configuración. Esto asegurará que comprenda cuánto espacio realmente consumirán sus datos en el motor de búsqueda. Para elasticsearch, depende de si está almacenando la fuente json y cómo se analizan los campos y si están almacenados.
EC2 puede ser una forma razonable de evaluar la búsqueda elástica sin un gran gasto h / w.
Para el software basado en clúster, como Elasticsearch, existen compensaciones entre mantener el clúster más pequeño o más grande. Un clúster grande es bueno porque cuando pierde un servidor, es necesario reasignar menos datos. Un grupo más pequeño consume menos energía y es más fácil de mantener.
Ejecutamos un clúster con 35 millones de documentos con un tamaño de índice total de alrededor de 300 GB x 2, ya que todos los índices se replican. Para admitir esto y una gran cantidad de búsquedas, tenemos 4 nodos, cada uno con 24 núcleos, 48 GB de RAM y 1 TB de almacenamiento con discos de 10K en raid10. Recientemente aumentamos el tamaño del disco para asegurarnos de tener más espacio para la cabeza.
Para su caso, recomendaría más RAM y más disco. Probablemente pueda ahorrar dinero en CPU con ese volumen de búsqueda.
El bajo volumen de búsqueda en realidad perjudica el rendimiento, ya que los cachés (tanto internos al s / w utilizado como al disco del sistema operativo) no se calentarán bien.
Espero que esto ayude, Paul