experiencias db4o?

Question

Actualmente estoy probando db4o (la versión de Java) y me gusta mucho lo que veo.Pero no puedo evitar preguntarme cómo funciona en un entorno (web) real en vivo.¿Alguien tiene alguna experiencia (buena o mala) que compartir sobre la ejecución de db4o?

Answer 1

Ejecutamos la versión DB40 .NET en un gran proyecto cliente/servidor.

Nuestra experiencia es que potencialmente se puede obtener un rendimiento mucho mejor que las bases de datos relacionales típicas.

Sin embargo, realmente tienes que modificar tus objetos para obtener este tipo de rendimiento.Por ejemplo, si tiene una lista que contiene muchos objetos, la activación de estas listas por parte de DB4O es lenta.Hay varias formas de solucionar este problema, por ejemplo, invirtiendo la relación.

Otro dolor es la activación.Cuando recupera o elimina un objeto de DB4O, de forma predeterminada se activará todo el árbol de objetos.Por ejemplo, cargar un Foo cargará Foo.Bar.Baz.Bat, etc. hasta que no quede nada por cargar.Si bien esto es bueno desde el punto de vista de la programación, el rendimiento se ralentizará cuanto más se aniden los objetos.Para mejorar el rendimiento, puede indicarle a DB4O cuántos niveles de profundidad activar.Esto lleva mucho tiempo si tienes muchos objetos.

Otra área problemática fue la búsqueda de texto.La búsqueda de texto de DB4O es mucho, mucho más lenta que la indexación de texto completo de SQL.(Te lo dirán directamente en su sitio). La buena noticia es que es fácil configurar un motor de búsqueda de texto sobre DB4O.En nuestro proyecto, hemos conectado Lucene.NET para indexar los campos de texto que queremos.

Algunas API no parecen funcionar, como las API GetField, útiles para aplicar actualizaciones de bases de datos.(Por ejemplo, ha cambiado el nombre de una propiedad y desea actualizar sus objetos existentes en la base de datos, necesita utilizar estas API de "reflexión" para buscar objetos en la base de datos.Otras API, como el atributo [Index] no funcionan en la versión estable 6.4 y, en su lugar, debes especificar índices usando Configure().Index("someField"), que no está fuertemente tipado.

Hemos sido testigos de que el rendimiento se degrada a medida que la base de datos es más grande.Tenemos una base de datos de 1 GB en este momento y las cosas siguen siendo rápidas, pero no tan rápidas como cuando comenzamos con una base de datos pequeña.

Encontramos otro problema en el que Db4O.GetByID cerrará la base de datos si el ID ya no existe en la base de datos.

Descubrimos que la sintaxis de consulta nativa (la sintaxis de consultas más natural e integrada en el lenguaje) es mucho, mucho más lenta que las consultas SODA menos amigables.Entonces en lugar de escribir:

// C# syntax for "Find all MyFoos with Bar == 23".
// (Note the Java syntax is more verbose using the Predicate class.)
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23);

En lugar de ese bonito código de consulta, tienes una fea consulta SODA que está basada en cadenas y no está fuertemente tipada.

Para la gente de .NET, recientemente introdujeron un proveedor LINQ-to-DB4O, que proporciona la mejor sintaxis hasta el momento.Sin embargo, aún está por verse si el rendimiento estará a la altura de las feas consultas de SODA.

El soporte de DB4O ha sido decente:Hemos hablado con ellos por teléfono varias veces y hemos recibido información útil.Sus foros de usuarios son prácticamente inútiles, pero casi todas las preguntas quedan sin respuesta.Su rastreador de errores JIRA recibe mucha atención, por lo que si tiene un error persistente, archívelo en JIRA para que con frecuencia se solucione.(Tuvimos 2 errores que se solucionaron y otro que se corrigió a medias).

Si todo esto no te ha asustado, déjame decirte que estamos muy contentos con DB4O, a pesar de los problemas que hemos encontrado.El rendimiento que tenemos ha superado algunos marcos O/RM que probamos.Lo recomiendo.

actualización julio 2015 Tenga en cuenta que esta respuesta se escribió en 2008.Si bien aprecio los votos a favor, el mundo ha cambiado desde entonces y es posible que esta información no sea tan confiable como lo era cuando se escribió.

Answer 2

La mayoría de las consultas nativas pueden convertirse y se convierten de manera eficiente en consultas SODA entre bastidores, por lo que eso no debería marcar la diferencia.Por supuesto, es preferible utilizar NQ ya que permanece en el ámbito del lenguaje tipográfico fuerte.Si tiene problemas para que NQ utilice índices, no dude en publicar su problema en foros de db4o y trataremos de ayudarte.

goran

Answer 3

El principal problema que he encontrado son los informes.Simplemente no parece haber ninguna forma de ejecutar informes eficientes en una fuente de datos db4o.

Answer 4

Judah, parece que no estás utilizando la activación transparente, que es una característica de la última versión de producción (7.4).¿Quizás si especificó la versión que está utilizando, ya que puede haber otros problemas que ahora están resueltos en la última versión?