Carga difusa de Hibernate y Hazelcast

Question

estamos utilizando ahora Hazelcast como caché de segundo nivel de Hibernate por un tiempo, pero estamos reconociendo largas demoras en el almacenamiento y la lectura de datos cuando se utilizan más de un nodo.

Hacemos un uso intensivo de objetos compuestos y relaciones @OneToMany, y para aumentar el rendimiento, decidimos cargar estos objetos compuestos o colecciones a través de la carga diferida de Hibernate. También implementamos DataSerializable para acelerar la serialización de Hazelcast, como se establece en la documentación de Hazelcast. ¡Pero registrar el uso de los métodos writeData/readData nos mostró que en realidad no se usaron!

No está claro para nosotros ahora, si el Proxy de Hibernate (que se utiliza mediante carga diferida) impide el uso de métodos DataSerializable (porque el proxy mismo podría (?) No implementar la interfaz) y, lo que es más importante, si Hazelcast admite la carga diferida en absoluto, ¡y cómo!

Answer 1

La dataSerializable de Hazelcast no tiene ningún uso con la memoria caché Hibernate L2, porque los objetos almacenados en el clúster Hazalcast no son objetos de su entidad. Hibernate usa su propio formato de datos (por ejemplo, serialización) en L2, convierte sus entidades y sus relaciones y colecciones a su propio formato y le da sus propios objetos (implementando java.io.Serializable) a Hazelcast. Hazelcast serializa aquellos que usan la serialización estándar de Java y los distribuye a través del clúster.

Si sus clases tienen un gráfico de objetos complejo y profundo (uso intensivo de objetos compuestos y 1xn o relaciones similares), este problema de serialización dual causa largos retrasos.

Hazelcast no tiene nada que ver con la carga lenta de Hibernate. Hibernate ya almacena entidades y sus relaciones y asignaciones de colecciones por separado. Entonces todos esos pueden ser cargados de Hazelcast uno por uno. Pero en su caso de uso, si la mayoría de las relaciones de carga diferida siempre están cargadas, eso ocasionará múltiples llamadas remotas de Hazelcast en lugar de una. Así que debes pensar cuidadosamente dónde usar la carga lenta.

Otro truco es usar/habilitar Hazelcast near-cache, si su aplicación es mayormente de solo lectura. (Por cierto, si no lo es, puede que usar caché L2 no sea adecuado para usted.) De esta forma, ahorrará muchas llamadas remotas y los datos que se necesitan con frecuencia se guardarán en la memoria caché localmente. Cerca de caché soporta todas las propiedades del mapa Hazelcast como TTL, desalojo, max-size etc.

Hazelcast Near-Cache documentation...