¿Cómo funciona el algoritmo de búsqueda por lotes de Hibernate?

Question

me encontré con esta descripción del algoritmo lotes ir a buscar en "Manning - Java Persistence con Hibernate":

Cuál es la verdadera lotes ir a buscar algoritmo? (...) Imagine un tamaño de lote de 20 y un número total de 119 proxies no inicializados que tienen que ser cargados en lotes. En el momento del inicio, Hibernate lee los metadatos de la asignación y crea 11 cargadores por lotes internamente. Cada cargador sabe cuántos proxies puede inicializar: 20, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1. El objetivo es minimizar el consumo de memoria para la creación del cargador y crear suficientes cargadores que cada lote posible se puede producir. Otro objetivo es para minimizar el número de SQL SELECT, obviamente. Para inicializar 119 proxies Hibernate ejecuta siete lotes (probablemente esperaba seis, porque 6 x 20> 119). Los cargadores de lotes que se aplican son cinco veces 20, una vez 10 y una vez 9, seleccionados automáticamente por Hibernate.

pero sigo sin entender cómo funciona.

1. ¿Por qué 11 cargadores de lotes?
2. ¿Por qué los cargadores por lotes pueden inicializar: 20, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 proxies?

Si alguien podría presentar un paso a paso algoritmo ... :)

Answer 1

no pude encontrar ninguna información en la web acerca de cómo maneja hibernación de carga por lotes, pero a juzgar por su información, se podría Supongo lo siguiente:

¿Por qué 11 cargadores de lotes?

Con un tamaño de lote de 20, si se desea reducir al mínimo el número de cargadores requerido para cualquier combinación de servidores proxy, hay básicamente dos opciones:

• crear un cargador de 1,2, 3,4,5,6,7, ... 20,21,22,23, ... N proxies no inicializados (¡estúpido!) O
• crea un cargador para cualquier N entre 1..9 y luego crea más cargadores para batch_size/2 (recursivamente)

Ejemplo: para el tamaño de lote 40, terminaría con cargadores para 40,20,10,9,8,7,6,5,4,3,2,1 cargadores.

1. Si tiene 33 proxies sin inicializar, puede utilizar los siguientes cargadores: 20, 10, 3
2. Si tiene 119 proxies sin inicializar, se pueden utilizar los siguientes cargadores, 40 (x2), 20, 10 , 9
3. ...

¿Por qué cargadoras lotes pueden inicializar: 20, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 proxies? Creo que el equipo de hibernación eligió esto como un equilibrio entre el número de cargadores necesarios para cargar un número "común" N de proxies no inicializados y el consumo de memoria. Podría haber creado un cargador para cada N entre 0 y batch_size, pero sospecho que los cargadores tienen una memoria considerable huella , por lo que esta es una compensación. El algoritmo puede ser algo como esto (conjetura):

1. n = batch_size; while (n > 10)

   1,1. loader(n); n = n/2

2. for n = 0..10 create loader(n)

Answer 2

Esto ayuda a evitar la creación de un gran número de diferentes declaraciones preparadas.

Cada consulta (preparado) debe analizarse y su plan de ejecución debe ser calculated and cached por la base de datos. Este proceso puede ser mucho más costoso que la ejecución real de la consulta para la cual la declaración ya ha sido almacenada en caché.

Una gran cantidad de sentencias diferentes pueden llevar a purgar otras declaraciones en caché de la memoria caché, lo que degrada el rendimiento general de la aplicación.

Además, como el análisis detallado suele ser muy costoso, generalmente es más rápido ejecutar múltiples instrucciones preparadas almacenadas en caché (incluidos múltiples viajes de ida y vuelta a la base de datos) que analizar y ejecutar uno nuevo. Entonces, además del beneficio obvio de reducir el número de declaraciones diferentes, en realidad puede ser más rápido recuperar todas las 119 entidades ejecutando 11 estados en caché que crear y ejecutar uno nuevo que contenga los 119 identificadores.

Como ya se mencionó en los comentarios, Hibernate invoca el método ArrayHelper.getBatchSizes para determinar los tamaños de lote para el tamaño máximo de lote dado.