c++ - BerkeleyDB Simultaneidad

berkeley-db (5)

¿Cuál es el nivel óptimo de concurrencia que la implementación C ++ de BerkeleyDB puede soportar razonablemente?
¿Cuántos hilos puedo tener martillando en el DB antes de que el rendimiento empiece a sufrir debido a la contención de recursos?

He leído el manual y sé cómo configurar el número de bloqueos, taquillas, tamaño de página de la base de datos, etc., pero me gustaría recibir algunos consejos de alguien que tenga experiencia en el mundo real con la concurrencia de BDB.

Mi aplicación es bastante simple. Haré get y pone records de 1KB cada uno. Sin cursores, sin eliminar.

Estoy totalmente de acuerdo con el punto de Daan: cree un programa de prueba y asegúrese de que la forma en que accede a los datos imita lo más posible los patrones que espera que tenga su aplicación. Esto es extremadamente importante con BDB porque los diferentes patrones de acceso producen un rendimiento muy diferente.

Aparte de eso, estos son factores generales que considero de mayor impacto en el rendimiento:

Método de acceso (que en tu caso supongo que es BTREE).
Nivel de persistencia con el que configuró DBD (por ejemplo, en mi caso, el indicador de entorno ''DB_TXN_WRITE_NOSYNC'' mejoró el rendimiento de escritura en un orden de magnitud, pero compromete la persistencia)
¿El conjunto de trabajo encaja en el caché?
Número de lecturas vs. Escribe
Cómo se extiende su acceso (recuerde que BTREE tiene un bloqueo de nivel de página, por lo que acceder a diferentes páginas con diferentes subprocesos es una gran ventaja).
Patrón de acceso: qué tan probable es que los hilos se bloqueen entre sí, o incluso que se bloqueen, y cuál es la política de resolución de interbloqueos (este puede ser un asesino).
Hardware (disco y memoria para caché).

Esto equivale al siguiente punto: Escalar una solución basada en DBD para que ofrezca una mayor concurrencia tiene dos formas clave de hacerlo; o minimice la cantidad de bloqueos en su diseño o agregue más hardware.

Lo que hice al trabajar contra una base de datos de rendimiento desconocido fue medir el tiempo de respuesta en mis consultas. Seguí subiendo el número de subprocesos hasta que se redujo el tiempo de respuesta, y disminuyendo el conteo de subprocesos hasta que mejoró el tiempo de respuesta (bueno, fueron los procesos en mi entorno, pero lo que sea).

Hubo promedios móviles y todo tipo de métricas involucradas, pero la lección para llevar fue: simplemente adaptarse a cómo están funcionando las cosas en este momento. Nunca se sabe cuándo los DBA mejorarán el rendimiento o si se actualizará el hardware, o tal vez llegue otro proceso para descargar el sistema mientras se está ejecutando. Así que adaptarse

Ah, y otra cosa: evite los interruptores de proceso si puede, por lotes.

Oh, debería dejar esto en claro: todo esto sucedió en el tiempo de ejecución, no durante el desarrollo.

¿Esto no depende tanto del hardware como del número de hilos y demás?

Haría una prueba simple y la ejecutaría con cantidades crecientes de hilos martillando y vería lo que parece mejor.

Depende del tipo de aplicación que esté creando. Cree un escenario de prueba representativo y comience a trabajar duro. Entonces sabrá la respuesta definitiva.

Además de su caso de uso, también depende de la CPU, la memoria, el bus frontal, el sistema operativo, la configuración de la caché, etcétera.

En serio, solo prueba tu propio escenario.

Si necesita algunos números (que en realidad pueden no significar nada en su escenario):

La forma en que entiendo las cosas, Samba creó tdb para permitir "múltiples escritores simultáneos" para cualquier archivo de base de datos en particular. Entonces, si su carga de trabajo tiene varios escritores, su rendimiento puede ser malo (como en el caso de que el proyecto Samba eligió escribir su propio sistema, aparentemente porque no estaba contento con el rendimiento de Berkeley DB en este caso).

Por otro lado, si su carga de trabajo tiene muchos lectores, entonces la pregunta es qué tan bien maneja su sistema operativo varios lectores.