Tengo una tarea para construir un prototipo para una aplicación de memoria compartida distribuida (DSM) masivamente escalable. El prototipo solo serviría como una prueba de concepto, pero quiero pasar el tiempo de la manera más efectiva seleccionando los componentes que se usarían en la solución real más adelante.Elegir una solución de memoria compartida distribuida
El objetivo de esta solución es tomar la entrada de datos de una fuente externa, batir y hacer el resultado disponible para un número de interfaces. Esas "interfaces" simplemente tomarían los datos del caché y lo servirían sin procesamiento adicional. La cantidad de visitas frontend a esta información puede ser literalmente de millones por segundo.
Los datos en sí son muy volátiles; puede (y lo hace) cambiar bastante rápido. Sin embargo, las interfaces deberían ver datos "antiguos" hasta que se haya procesado y almacenado el más nuevo. El procesamiento y la escritura se realizan mediante un único nodo (redundante) mientras que otros nodos solo leen los datos. En otras palabras: sin comportamiento de lectura.
que estaba buscando en soluciones como memcached sin embargo éste en particular no cumple con todos los nuestros requisitos que se enumeran a continuación:
- La solución debe tener al menos Java API del cliente que es razonablemente bien mantenido ya que el resto de la aplicación está escrita en Java y somos experimentados desarrolladores de Java;
- la solución debe ser totalmente elástico: debe ser posible añadir nuevos nodos sin reiniciar otros nodos en el cluster;
- La solución debe ser capaz de manejar conmutación por error. Sí, me doy cuenta de que esto significa un poco de sobrecarga, pero el tamaño total de los datos servidos no es grande (1G máximo), así que esto no debería ser un problema. Por "conmutación por error" me refiero a la ejecución sin fisuras sin codificación/cambio de dirección (es) IP del servidor, como en los clientes memcached cuando un nodo deja de funcionar;
- Idealmente, debería ser posible especificar el grado de superposición de datos (por ejemplo, cuántas copias de los mismos datos deben almacenarse en el clúster de DSM);
- No es necesario almacenar permanentemente todos los datos, pero puede haber una necesidad de procesamiento posterior de algunos de los datos (por ejemplo, serialización a la base de datos).
- Precio. Obviamente, preferimos la fuente gratuita/abierta, pero nos complace pagar una cantidad razonable si la solución vale la pena. En cualquier caso, el contrato de soporte 24 horas al día es obligatorio.
- Toda cosa tiene que ser alojado en nuestros centros de datos ofertas de modo SaaS como Amazon SimpleDB están fuera de alcance. Solo consideraríamos esto si no hubiera otras opciones disponibles.
- Idealmente, la solución sería estrictamente consistente (como en CAP); sin embargo, consistencia eventual se puede considerar como una opción.
Gracias de antemano por cualquier idea.
Gracias, en realidad estamos usando Hazelcast en uno de nuestros otros proyectos.Hablando honestamente, esperaba que alguien sugiriera usar algo como Project Voldemort y dar una idea de cómo funciona esa escala (para los requisitos que he mencionado), principalmente porque Hazelcast parece ser una biblioteca de amplio uso mientras que proyectos como Voldemort son DSM específicos basados en mapas. Por supuesto, no estoy tratando de decir que Hazelcast no soportará la carga, esto necesita ser medido y probado. – mindas
Acaba de darse cuenta de que eres uno de los autores de Hazelcast. Whoops :) – mindas
Sí, soy uno de los autores :) Hazelcast Distributed Map es un DSM basado en un mapa específico. Para obtener la escalabilidad, consulte nuestra demostración de clúster de 100 nodos en http://java.dzone.com/articles/running-hazelcast-100-node. –