¿Puedo usar Terracotta para escalar una aplicación intensiva de RAM?

Question

Estoy evaluando Terracotta para ayudarme a escalar una aplicación que actualmente está limitada por RAM. Es un filtro colaborativo y almacena aproximadamente 2 kilobytes de datos por usuario. Quiero usar el EC2 de Amazon, lo que significa que estoy limitado a 14 GB de RAM, lo que me da un límite superior efectivo por servidor de alrededor de 7 millones de usuarios. Necesito poder escalar más allá de esto.

De acuerdo con mi lectura hasta ahora, me consta que Terracotta puede tener un montón agrupado más grande que la RAM disponible en cada servidor. ¿Sería viable tener un montón agrupado eficaz de 30 GB o más, donde cada uno de los servidores solo admite 14 GB?

Los datos por usuario (la mayor parte de los cuales son matrices de carrozas) cambian con mucha frecuencia, posiblemente cientos de miles de veces por minuto. No es necesario que cada uno de estos cambios se sincronice con otros nodos en el clúster en el momento en que ocurren. ¿Es posible sincronizar solo algunos campos de objetos periódicamente?

Answer 1

Yo diría que la respuesta es afirmativa. Terracotta te permite trabajar con montones agrupados más grandes que el tamaño de una JVM única, aunque ese no es el caso de uso más común.

Aún debe tener en cuenta a) el tamaño del conjunto de trabajo yb) la cantidad de tráfico de datos. Para a), hay algún conjunto de datos que debe estar en la memoria para realizar el trabajo en un momento dado y, si ese tamaño de conjunto de trabajo> tamaño del montón, el rendimiento obviamente sufrirá. Para b), cada elemento de datos agregado/actualizado en el montón agrupado debe enviarse al servidor. Terracota es mejor cuando se cambian los campos de grano fino en los gráficos pojo. Trabajar con grandes arreglos no aprovecha al máximo las capacidades de Terracota (lo que no quiere decir que las personas no lo utilicen de esa manera a veces).

Si está creando una gran cantidad de basura, los administradores de memoria de Terracotta y el recolector de basura distribuido deben poder mantenerse al día con eso. Es difícil de decir sin probar si sus volúmenes de datos exceden el ancho de banda disponible allí.

Su aplicación se beneficiará enormemente si ejecuta varios servidores y los datos son particionados por el servidor o tiene cierta cantidad de localidad de referencia. En ese caso, solo necesita los datos para la partición de un servidor en el montón y el resto no tiene que tener una falla en la memoria. Por supuesto, tendrá una falla si es necesario para failover/disponibilidad si otros servidores se caen. Lo que esto significa es que en el caso de los datos con particiones, no está transmitiendo a todos los nodos, solo enviando transacciones al servidor.

Desde el punto de vista de los números, es posible indexar 30 GB de datos, por lo que no está cerca de ningún límite estricto.