¿Cómo optimizar la hibernación?
Por lo general, las principales consideraciones para el ajuste del rendimiento de HIBERNATE son las siguientes:
* Ajuste del diseño de la base de datos
* Optimización HQL
* API Uso correcto (como seleccionar diferentes API de recopilación y consulta según diferentes tipos de negocio)
*Parámetros de configuración principales (registro, caché de consultas, fetch_size, batch_size, etc.)
*Mapeo Optimización de archivos (estrategia de generación de ID, caché L2, carga diferida, optimización de correlación)
* Gestión de caché L1
* El caché L2 tiene muchas estrategias únicas.
*Estrategia de control de transacciones.
1. Diseño de bases de datos
a) Reducir la complejidad de la asociación
b) Intentar no utilizar claves primarias conjuntas.
C) Mecanismo de generación de ID. Diferentes bases de datos proporcionan diferentes mecanismos.
d) Datos adecuadamente redundantes y no perseguir excesivamente altos paradigmas.
2.Optimización HQL
Si HQL abandona la asociación con algunos mecanismos de almacenamiento en caché del propio HIBERNATE, entonces sus habilidades de optimización son las mismas que las de SQL normal, y es fácil encontrar algunas en la experiencia de Internet.
3. Configuración principal
a) La caché de consultas, a diferencia de la caché mencionada a continuación, es la caché de declaraciones HQL, es decir, los datos almacenados en caché se pueden usar cuando se realiza la misma declaración. se ejecuta nuevamente. Sin embargo, el almacenamiento en caché de consultas puede ser contraproducente en un sistema comercial (los datos cambian con frecuencia y la probabilidad de que se produzcan las mismas condiciones de consulta es baja): consumirá una gran cantidad de recursos del sistema en vano, pero es difícil utilizarlos.
B) fetch_size, similar a los parámetros JDBC, cuanto mayor sea el parámetro, mejor, pero debe configurarse de acuerdo con las características comerciales.
C) el tamaño del lote es el mismo que el anterior.
d) En el sistema de producción, recuerde desactivar la impresión de sentencias SQL.
4. Objetos ocultos
a) Caché a nivel de base de datos: este nivel de caché es el más eficiente y seguro, pero diferentes bases de datos pueden administrar diferentes niveles. Por ejemplo, en ORACLE, puede especificar que toda la tabla se coloque en la memoria caché cuando se crea la tabla.
b) Caché de sesión (caché de SESSION): Efectivo en sesiones de HIBERNATE. Este nivel de caché no es intrusivo y HIBERNATE lo administra principalmente de forma automática, pero proporciona un método para borrar el caché en una gran cantidad. de adiciones / Válido durante las operaciones de actualización. Por ejemplo, si agrega 100.000 registros al mismo tiempo y continúa de forma normal, lo más probable es que encuentre la excepción OutofMemory. En este momento, es posible que deba borrar manualmente el caché en este nivel: Session.evict y Session.clear
c) Caché de la aplicación: es efectivo en SESSIONFACTORY, por lo que también es la máxima prioridad de optimización. . Entonces se consideraron varias estrategias. Antes de colocar datos en este nivel de almacenamiento en caché, hay algunos requisitos previos a considerar:
Los datos no serán modificados por terceros (por ejemplo, ¿hay otra aplicación que también modifica los datos?)
p>Dos. Los datos no serán demasiado grandes.
Tres. Los datos no se actualizarán con frecuencia (de lo contrario, el uso del almacenamiento en caché podría resultar contraproducente).
Cuatro. Los datos se consultarán con frecuencia.
Los datos del verbo (abreviatura de verbo) no son datos críticos (por ejemplo, relacionados con dinero, seguridad, etc.).
El caché tiene varias formas y se puede configurar en el archivo de mapeo. : solo lectura (solo lectura, adecuado para datos estáticos/datos históricos que rara vez cambian), lectura no estricta y lectura y escritura no estrictas (una forma común, eficiencia promedio), tipo de transacción (JTA, admite menos productos de almacenamiento en caché) .
d) Caché distribuido: la configuración es la misma que en c), pero la selección de productos de caché es diferente. Actualmente, no hay muchas opciones en HIBERNATE.
En la actualidad, la mayoría de los proyectos, como Oscar oscache y jboss cache, tienen una actitud conservadora hacia su uso en clústeres (especialmente sistemas de transacciones clave). En un entorno agrupado, lo más seguro es utilizar únicamente el almacenamiento en caché a nivel de base de datos.
5. Carga retrasada
a) Carga retrasada de entidades: se consigue mediante el uso de proxies dinámicos.
b) Carga diferida de colecciones: HIBERNATE proporciona este soporte implementando sus propias colecciones/listas.
c) Atributos de carga diferida:
6. Selección de método
a) Para lograr lo mismo, HIBERNATE proporciona algunos métodos para elegir, pero lo específico La forma en que se usa puede tener implicaciones de rendimiento/código. Es probable que mostrar 100.000 registros devueltos a la vez (lista/conjunto/paquete/gráfico, etc.) cause problemas de falta de memoria, pero si utiliza un conjunto de resultados basado en cursores (ScrollableResults) o iteradores, este problema no existe.
b) El método cargar/obtener de la sesión, el primero utilizará el caché de segundo nivel, pero el segundo no.
c)Consultas y listas/iteradores. Si los estudias detenidamente, podrás encontrar muchas situaciones interesantes. La principal diferencia entre ellos es (si usa Spring, los métodos de búsqueda e iterador corresponden a HibernateTemplate):
I. la lista solo puede usar el caché de consultas (pero el caché de consultas no juega un papel en el comercio). sistema grande), no se pueden utilizar entidades individuales de la caché L2. Sin embargo, los objetos encontrados en la lista se escribirán en la caché de segundo nivel, pero generalmente solo genera unas pocas declaraciones SQL y, en muchos casos, solo una (irrelevante).
Dos. Los iteradores pueden utilizar caché de segundo nivel. Para una declaración de consulta, primero encontrará los ID de todos los registros que cumplan las condiciones de la base de datos y luego los almacenará en caché según los ID. Para los registros que no están en la caché, construye una declaración para encontrarlos en la base de datos. Por lo tanto, es fácil saber que si no hay registros calificados en el caché, el uso del iterador generará N+1 declaraciones SQL (N es el número de registros calificados).
Tres. Con la ayuda de iteradores y API de administración de caché, los problemas de memoria en consultas de datos masivas se pueden resolver bien, como:
while(it.hasNext()){
YouObject object = ( YouObject)it . next();
session . evict(tu objeto);
session factory evice(tu objeto . clase, tu objeto . getid());
p>
}
Si utiliza el método de lista, puede obtener un error de OutofMemory.
De la explicación anterior, creo que deberías saber cómo utilizar estos dos métodos.
7. Selección del paquete de instrumentos
Se explica en detalle en "19.5". Obtenga más información sobre el "Rendimiento de la colección" para la documentación de HIBERNATE 3.1.
8. Control de transacciones
Las transacciones tienen un impacto en el rendimiento, incluida la elección del modo de transacción, el nivel de aislamiento de la transacción y la selección de bloqueo.
a) Selección del modo de transacción: si no participan varios administradores de transacciones, no se necesita JTA, solo el control de transacciones JDBC es suficiente.
b) Nivel de aislamiento de transacciones: consulte el nivel de aislamiento de transacciones SQL estándar.
c) Selección de bloqueo: Los bloqueos pesimistas (generalmente implementados por un administrador de transacciones específico) son menos eficientes, pero son seguros para transacciones largas. El bloqueo optimista (generalmente implementado a nivel de aplicación), como el campo de versión, se puede definir en HIBERNATE. Obviamente, el bloqueo optimista fallará si hay varias aplicaciones que manipulan datos que no utilizan el mismo mecanismo de bloqueo optimista. Por tanto, diferentes datos deberían tener diferentes estrategias. Como en muchos casos anteriores, muchas veces encontramos un equilibrio entre eficiencia y seguridad/precisión. En cualquier caso, la optimización no es una cuestión puramente técnica; debe tener un conocimiento suficiente de su aplicación y las características comerciales.
9. Operación por lotes
Incluso si se utiliza JDBC, al actualizar una gran cantidad de datos, la eficiencia del procesamiento por lotes y el procesamiento no por lotes es muy diferente. Podemos admitir operaciones por lotes configurando el tamaño de lote.
Por ejemplo, si desea eliminar objetos en una tabla en lotes, como "Eliminar cuenta", encontrará que HIBERNATE encuentra los ID de todas las cuentas y luego las elimina. Esto es principalmente para mantener el caché de segundo nivel, por lo que la eficiencia definitivamente no es alta. La eliminación/actualización por lotes se agregó en versiones posteriores, pero esto no resuelve el problema del mantenimiento de la caché. En otras palabras, debido al problema de mantenimiento del caché de segundo nivel, la eficiencia de la operación por lotes de HIBERNATE no es satisfactoria.