Elegir entre Berkeley DB Core y Berkeley DB JE

Question

Estoy diseñando una aplicación web basada en Java y necesito un almacén de clave-valor. Berkeley DB parece bastante adecuado para mí, pero parece que hay 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 convertirá 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 Java de Cores, pero me cuesta creer que pueda ser mucho peor que las ediciones Java, que parece ser bastante agradable.

Si algún otro almacén de valores-clave fuera mucho mejor, no dude en recomendarlo también. Estoy almacenando blobs binarios pequeños, y las claves probablemente serán hash de los datos, o alguna otra identificación única.

Answer 1

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

Answer 2

Me enfrenté al mismo problema y decidí optar por la edición Java, principalmente por su portabilidad (necesito algo que se ejecute incluso en dispositivos móviles). También existe la API de capa de persistencia directa (Direct Persistence Layer, DPL) y el hecho de que toda la base de datos sea un solo contenedor hace que su implementación sea bastante simple.

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

Se adapta perfectamente a cualquier aplicación Java: de escritorio o web.

Answer 3

Hace un tiempo tuve la misma pregunta, después de hacer algunos benchmarks encontré que el modo hash en la edición nativa es mucho más rápido y eficiente en almacenamiento que cualquier cosa que la edición java tenga para ofrecer, así que decidí irme con el nativo implementación.

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

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

por ttulo: mi punto de referencia fue probar la velocidad de consultar claves aleatorias de 20,000,000 de registros, donde la clave es una cadena y el valor es un int (4 bytes). Vi que las inserciones (llenando el punto de referencia) era mucho más rápida con la versión nativa, y las consultas eran dos veces más rápidas.

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

Answer 4

Tengo mucha experiencia en el uso de BDB-JE y BDB-core con Java. Decidir cuál usar es bastante simple: si quieres concurrencia, usa BDB-JE. Si quieres escalabilidad, usa BDB-core.

BDB-JE se rompe en cuanto a rendimiento con bases de datos grandes debido a su formato de archivo y su dependencia de la recolección de basura de Java para limpiar las entradas de caché expulsada. Espere largas pausas de recolección de basura o dedique mucho tiempo a ajustar la configuración mágica de GC.El formato de archivo también tiene problemas, porque los hilos del limpiador de fondo tienen que pasar mucho tiempo limpiando la basura creada por los primeros desalojos de caché. Si su base de datos cabe en RAM, BDB-JE funciona bastante bien.

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

Answer 5

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

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