Optimizando el desempeño de Put en Berkeley DB

Question

Acabo de empezar a jugar con Berkeley DB hace unos días, así que estoy tratando de ver si hay algo que me faltaba cuando se trata de almacenar datos lo más rápido posible.

aquí hay algo de información sobre los datos: - se trata en 512 trozos de bytes - trozos vienen con el fin - trozos se eliminarán en orden FIFO - Si pierdo algunos datos fuera de la final debido a la falta de energía eléctrica que está bien siempre y cuando todo el archivo db no se haya roto

Después de leer un montón de la documentación, parecía que un Quebe db era exactamente lo que quería.

Sin embargo, después de probar algún código de prueba, mis resultados más rápidos fueron de aproximadamente 1MByte por segundo, simplemente haciendo un bucle a través de un DB-> puesto con el conjunto DB_APPEND. También traté de usar transacciones y posiciones masivas, pero ambas disminuyeron la velocidad considerablemente, así que no las seguí por mucho tiempo. Estaba insertando en un db nuevo creado en un chip NANDFlash en mi placa de desarrollo Freescale i.MX35.

Como buscamos velocidades de escritura de al menos 2MBytes por segundo, me preguntaba si hay algo que omito que puede mejorar mis velocidades ya que sé que mi hardware puede escribir más rápido que esto.

Answer 1

trate de poner esto en su DB_CONFIG:

set_flags DB_TXN_WRITE_NOSYNC 
set_flags DB_TXN_NOSYNC 

Desde mi experiencia, estas a aumentar el rendimiento de escritura mucho.

---

DB_TXN_NOSYNC Si se establece, Berkeley DB no escribirá de forma sincrónica o vaciar el registro de confirmación de transacción o preparar. Esto significa que las transacciones exhiben las propiedades ACI (atomicidad, consistencia y aislamiento), pero no D (durabilidad); es decir, se mantendrá la integridad de la base de datos, pero si la aplicación o el sistema fallan, es posible que se deshaga una cantidad de las transacciones confirmadas más recientemente durante la recuperación. El número de transacciones en riesgo se rige por la cantidad de actualizaciones de registro que pueden caber en el búfer de registro, la frecuencia con que el sistema operativo vacía los búferes sucios en el disco y la frecuencia con la que se identifica el registro Llamar DB_ENV-> set_flags con el indicador DB_TXN_NOSYNC solo afecta el asa DB_ENV especificada (y cualquier otro asa de Berkeley DB abierta dentro del alcance de ese asa). Para un comportamiento uniforme en todo el entorno, todos los identificadores DB_ENV abiertos en el entorno deben establecer el indicador DB_TXN_NOSYNC o el indicador debe especificarse en el archivo de configuración DB_CONFIG.

La marca DB_TXN_NOSYNC se puede usar para configurar Berkeley DB en cualquier momento durante la vida de la aplicación.

---

DB_TXN_WRITE_NOSYNC Si se establece, Berkeley DB va a escribir, pero no lo hará de forma sincrónica al ras, el registro de confirmación de transacción o preparar. Esto significa que las transacciones exhiben las propiedades ACI (atomicidad, consistencia y aislamiento), pero no D (durabilidad); es decir, se mantendrá la integridad de la base de datos, pero si el sistema falla, es posible que algunas de las transacciones comprometidas más recientes se deshagan durante la recuperación. El número de transacciones en riesgo se rige por la frecuencia con la que el sistema vacía los búfers sucios en el disco y la frecuencia con la que se marca el registro. Llamar a DB_ENV-> set_flags con el flag DB_TXN_WRITE_NOSYNC solo afecta el manejador DB_ENV especificado (y cualquier otro manejador de Berkeley DB abierto dentro del alcance de ese manejador).Para un comportamiento uniforme en todo el entorno, todos los identificadores DB_ENV abiertos en el entorno deben establecer el indicador DB_TXN_WRITE_NOSYNC o el indicador debe especificarse en el archivo de configuración DB_CONFIG.

La marca DB_TXN_WRITE_NOSYNC se puede usar para configurar Berkeley DB en cualquier momento durante la vida de la aplicación.

Ver http://www.mathematik.uni-ulm.de/help/BerkeleyDB/api_c/env_set_flags.html para más detalles.

Answer 2

Sugiero que debe usar las transacciones/el almacén de datos TDS si, como mencionas, no puedes volver a crear una base de datos (es decir, no es solo una caché local) si se corrompe. Si no le importa perder algunos artículos en caso de un fallo/corte de energía, entonces DB_TXN_WRITE_NOSYNC mejorará el rendimiento de TDS, su base de datos seguirá siendo integral y recuperable. Si almacena usando BTREE y un índice numérico (si no tiene una clave natural) y está atento a los problemas endian para que obtenga una buena ubicación clave y una alta utilización de páginas, entonces podrá obtener más de 2000 inserciones por segundo, especialmente a SSD, especialmente si usa DbMultileKeyDataBuilder para hacer inserciones masivas.