Elegir entre Berkeley DB Core y Berkeley DB JE

Question

Estoy diseñando una aplicación web basada en Java y necesito una tienda de valor clave. Berkeley DB parece apropiado para mí, pero parece haber dos DB de Berkeley para elegir: Berkeley DB Core que se implementa en C, y Berkeley DB Java Edition que se implementa en Java puro.

La pregunta es, ¿cómo elegir cuál usar? Con la escalabilidad y el rendimiento de las aplicaciones web es bastante importante (quién sabe, tal vez mi idea se convierta en el próximo YouTube), y no pude encontrar fácilmente ningún punto de referencia significativo entre los dos. Todavía tengo que familiarizarme con la API de Java de núcleos, pero me resulta difícil creer que podría ser mucho peor que las ediciones de Java, lo que parece ser bastante agradable.

Si alguna otra tienda de valores clave sería mucho mejor, no dude en recomendarlo también. Estoy almacenando gotas binarias pequeñas, y las claves probablemente serán hash de los datos, o alguna otra identificación única.

Answer 1

Si obtiene una interfaz común a estos y tiene un conjunto adecuado de pruebas unitarias, debería poder intercambiar entre los dos trivialmente en una fecha posterior (tal vez cuando realmente necesita tomar una decisión basada en hechos duros que no están disponibles en este momento)

Answer 2

Tengo bastante experiencia usando BDB-JE y BDB-core con Java. Decidir cuál usar es bastante simple: si desea concurrencia, use bdb-je. Si desea escalabilidad, use BDB-Core.

BDB-JE desglosa en cuanto al rendimiento con grandes bases de datos debido a su formato de archivo y su dependencia de la recolección de basura de Java para limpiar las entradas de caché desalojadas. Espere pausas de recolección de basura larga o pase mucho tiempo ajustando la configuración de GC mágico. El formato de archivo también tiene problemas, porque los hilos de limpieza de fondo tienen que pasar mucho tiempo limpiando la basura creada por los primeros desalojos de caché. Si su base de datos se ajusta a RAM, BDB-JE funciona bastante bien.

BDB-Core se basa en una estrategia de bloqueo de páginas, y las aplicaciones altamente concurrentes experimentan muchos puntos muertos. Si puede ordenar al azar las operaciones, reduce el potencial de punto muerto, pero nunca lo elimina. Debido a que BDB-Core almacena datos de una manera más tradicional, se escala a tamaños súper grandes con degradación predecible y esperada del rendimiento. Debido a que su caché no es administrado por un recolector de basura, puede ser bastante grande y no causar pausas.

Answer 3

Me enfrenté al mismo problema y decidí ir con la edición Java, principalmente debido a su portabilidad (necesito algo que se ejecutara incluso en dispositivos móviles). También hay la API de la capa de persistencia directa (DPL) y el hecho de que todo el DB es un solo frasco hace que su implementación sea bastante simple.

La reciente versión 4 trajo una alta disponibilidad y mejoras de rendimiento. También existe el hecho de que las aplicaciones Java de larga duración pueden lograr tal optimización, que superarían el rendimiento de las aplicaciones C nativas en algunos escenarios.

Es un ajuste natural para cualquier aplicación Java: escritorio o web.

Answer 4

Mientras que tenía la misma pregunta, después de hacer algunos puntos de referencia, descubrí que el modo hash en la edición nativa es mucho más rápido y eficiente de almacenamiento que cualquier cosa que la edición Java tenga para ofrecer, así que decidí ir con la implementación nativa.

Le sugiero que haga sus propios puntos de referencia para las capacidades de almacenamiento que espera y decida si la edición Java es lo suficientemente rápida.

Si es así, o si el rendimiento no es un gran problema para usted (es crítico para mí), simplemente vaya con la edición Java. De lo contrario, vaya al nativo (suponiendo que vea el mismo aumento de rendimiento para su propio caso de uso).

Por cierto: mi punto de referencia fue probar la velocidad de consultar las claves aleatorias de 20,000,000 de registros, donde la clave es una cadena y el valor es un int (4 bytes). Vi que los insertos (poblando el punto de referencia) era mucho más rápido con la versión nativa, y las consultas fueron el doble de rápido.

(Esto no se debe a la deficiencia de Java, sino a que la versión Java no es de la misma versión que la versión nativa - 4.0 vs 4.8 IIRC).

Answer 5

Decidí ir con la edición Java, simplemente porque es posible incrustar el tiempo de ejecución de la base de datos dentro del mismo desplegable. Esta fue una característica importante para mi configuración. No he comparado entre Core y JE, pero he visto un gran rendimiento en comparación con otras tiendas de valor clave que probé al evaluar por primera vez las tiendas de bases de datos.

Sin embargo, si está creando una aplicación web, entonces la concurrencia podría ser muy importante para usted a largo plazo.