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 real en vivo (web). ¿Alguien tiene alguna experiencia (buena o mala) para compartir sobre ejecutar db4o?db4o experiences?
Ejecutamos la versión DB40 .NET en un gran proyecto cliente/servidor.
Nuestra experiencia es que potencialmente puede obtener un rendimiento mucho mejor que las bases de datos relacionales típicas.
Sin embargo, realmente tiene que ajustar sus objetos para obtener este tipo de rendimiento. Por ejemplo, si tiene una lista que contiene muchos objetos, la activación de DB4O de estas listas es lenta. Hay varias formas de evitar 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 activará todo el árbol de objetos. Por ejemplo, cargar un Foo cargará Foo.Bar.Baz.Bat, etc. hasta que no quede nada para cargar. Si bien esto es agradable desde el punto de vista de la programación, el rendimiento disminuirá la cantidad de anidamiento en sus objetos. Para mejorar el rendimiento, puedes decirle a DB4O cuántos niveles profundos activar. Esto lleva mucho tiempo si tienes muchos objetos.
Otra área de dolor 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. (Le dirán esto 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 parecen no funcionar, como las API de GetField que son útiles para aplicar actualizaciones de bases de datos. (Por ejemplo, si ha cambiado el nombre de una propiedad y desea actualizar sus objetos existentes en la base de datos, debe usar estas API de "reflexión" para buscar objetos en la base de datos. Otras API, como el atributo [Índice] don ' t funciona en la versión estable 6.4, y en su lugar debe especificar índices utilizando Configure(). Index ("someField"), que no está fuertemente tipado.
Hemos observado un rendimiento degradado cuanto mayor es su base de datos. una base de datos de 1GB ahora y las cosas siguen siendo rápidas, pero no tan rápido como cuando comenzamos con una pequeña base de datos.
Hemos encontrado otro problema donde Db4O.GetByID cerrará la base de datos si la ID no existe más en la base de datos.
Hemos encontrado que la sintaxis Native Query (la sintaxis más natural e integrada en el lenguaje para las consultas) es mucho, mucho más lenta que las consultas SODA menos amigables. Así que 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 buen código de consulta, que tiene a una consulta de SODA feo que es y no inflexible de tipos basado en cadena.
Para .NET amigos, recientemente han presentado 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.
La compatibilidad con DB4O ha sido decente: hemos hablado con ellos por teléfono varias veces y hemos recibido información útil. Sus foros de usuarios son inútiles, sin embargo, casi todas las preguntas quedan sin respuesta. Su rastreador de errores JIRA recibe mucha atención, por lo que si tienes un error molesto, archivarlo en JIRA suele solucionarse. (Hemos tenido 2 errores que se han corregido, y otro que se parchó de una manera 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 hemos obtenido ha destruido algunos marcos O/RM que probamos. Lo recomiendo.
actualización Julio de 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 esta información puede no ser tan confiable como lo fue cuando se escribió.
El principal problema con el que me he encontrado es informar. Simplemente no parece haber ninguna forma de ejecutar informes eficientes contra una fuente de datos db4o.
A veces se recomienda enviar datos para informar a un servidor SQL o a un buen almacén de datos para la generación de informes. Será más fácil de esta manera porque puede desnormalizar este almacenamiento para facilitar la generación de informes. –
La mayoría de las consultas nativas se pueden y se convierten de manera eficiente en consultas de SODA entre bastidores, por lo que no deberían marcar la diferencia. El uso de NQ es, por supuesto, preferido ya que permaneces en los reinos del lenguaje fuerte. Si tiene problemas para que NQ use índices, no dude en publicar su problema en el db4o forums y trataremos de ayudarlo.
Goran
Judá, parece que no está utilizando la activación transparente, lo cual es una característica de la versión más reciente producción (7,4)? ¿Tal vez si especificó la versión que está utilizando, ya que puede haber otros problemas que ahora se resuelven en la última versión?
En el momento de escribir esto, estábamos usando 6.4. Ahora estamos usando 7.8. Sin embargo, todavía no utilizamos la activación transparente porque nos obliga a cambiar todos nuestros tipos de listas para usar listas DB4O. –
¿Cómo conseguiste que la implementación de tu servidor no se bloqueara al procesar una consulta? Hemos implementado (I HOPE!) Una evaluación de cliente/servidor bastante ingenua, y observamos que las consultas de larga ejecución bloquean el procesamiento del servidor. Nuestras operaciones perf-client son todas de solo lectura. –
Un par de cosas que puedes probar: múltiples bases de datos, tal vez una para cada usuario. Puede utilizar el modo cliente/servidor DB4O, en lugar del modo incrustado, que maneja el subprocesamiento de forma un poco diferente. –
¡Hola Judah! En cuanto a los problemas que mencionó, la profundidad de activación está configurada por defecto en 5, por lo que db4o dejará de activar objetos en profundidad 5. También puede probar la activación transparente (ahora db4o admite las colecciones nativas) y db4o activar sus objetos solo cuando sea necesario (cuando se usa objeto). En cuanto a Linq, consultas nativas y SODA, en la mayoría de los casos no debe tener una diferencia de rendimiento perceptible (el caso más común para tales diferencias está relacionado con db4o no encontrar ensamblados necesarios, como Mono.Cecil.dll, Db4objects.Db4o.Instrumentation y Cecil .FlowAnalysis). – Vagaus