Memoria principal DB vs Objeto DB

Question

Actualmente estoy tratando de elegir un proveedor de base de datos.

Sólo estoy buscando algunas opiniones personales de los desarrolladores de bases de datos compañeros por ahí.

Mi pregunta está especialmente dirigido a las personas que:

1) han utilizado Memoria principal DB (MMDB) que soporta la replicación en el disco (híbrido) antes (es decir eXtremeDB )

o

2) han utilizado Versant base de datos de objetos y / o objetividad base de datos y / o Progreso ObjectStore

y la cuestión es realmente:. Si podría recomendar un proveedor de base de datos, basándose en su experiencia, que se adapte a mi solicitud

Mi aplicación es un comercial en tiempo real (es decir: de alto rendimiento) orientado a objetos C ++ tipo GIS de aplicación, donde tenemos que hacer un montón de lat búsqueda / lon (es decir, dada una zona, encontrar todos los blancos a juego dentro de del área ... índice de árbol R).

Los tipos de datos que desea almacenar en la base de datos están todos modelados como objetos y hacen uso de std :: lista y std :: vector, lo que, naturalmente, la base de datos de objetos parece tener sentido. He leído a través de artículos suficientes para convencerme de que un RDBMS tradicional probablemente tampoco lo que realmente estoy buscando en términos de

1. Rendimiento (se une o múltiple tablas de datos de longitud dinámica como lista / vector)
2. facilidad de programación (Impedancia de falta de coincidencia)

Sin embargo, en términos de rendimiento,

1. Los datos de entrada se introduce en el sistema a aproximadamente 40 MB / s.

2. Por lo tanto, el sistema también estará haciendo inserción en la base de datos a la velocidad de aproximadamente 350 inserciones por segundo (donde cada objeto varía de 64 KB a 128 KB),

3. Base de datos consistentemente será buscado y actualizar a través de varios subprocesos.

A mi entender, todos los DBs de objetos que he mencionado aquí utilizan caché para almacenar objetos de base. EXtremeDB afirma que ya que está diseñado especialmente para la memoria, se puede evitar la sobrecarga de la lógica de almacenamiento en caché, etc. Ver más buscando en Google: Memoria principal frente del disco RAM en las bases de datos: un punto de referencia basado en Linux

So..I'm sólo un poco confundido. Puede oponerse DBs ser utilizados en el sistema en tiempo real? ¿Es tan "rápido" como MMDB?

Answer 1

En el fondo, me diferencia entre un MMDB y una OODB es que el MMDB tiene la expectativa de que todos sus datos se basa en la memoria RAM, pero persistió en el disco en algún momento. Mientras que un OODB es más convencional en que no hay expectativa de todo el montaje DB en la memoria RAM.

El MMDB puede aprovechar esta renunciando a la idea de que los datos PERSISTED no tiene necesariamente que los datos de "correspondencia" en la memoria RAM.

La forma en nada con la persistencia va a funcionar, es que tiene que escribir los datos en el disco en la actualización de alguna manera.

Casi todos los DBs utilizan algún tipo de registro para este. Estos registros son básicamente páginas "en bruto" de datos, o tal vez las transacciones individuales, adjuntas a un archivo. Cuando el archivo se "demasiado grande", se inicia un nuevo archivo.

Una vez que los registros estén correctamente consolidan en la tienda principal, los registros se descartan (o reutilizados).

Ahora, un crudo, en la memoria RAM DB puede existir simplemente añadiendo transacciones a un archivo de registro, y cuando se reinicia, sólo se carga el registro en la memoria RAM. Así que, en esencia, el archivo de registro es la base de datos.

La desventaja de esta técnica es la más larga y más transacciones que usted tiene, su registro / DB es, y por lo tanto mayor será el tiempo de inicio de DB más grande. Pero, idealmente, puede también "instantánea" de la situación actual, lo que elimina todos los registros hasta la fecha, y efectivamente los comprime.

De esta manera, todas las operaciones rutinarias de la base de datos se tienen que gestionar añadiendo páginas a los registros, en lugar de la actualización de otras páginas de disco, las páginas de índice, etc. Dado que, idealmente, la mayoría de los sistemas no necesitan "Encendido" que a menudo, tal vez el tiempo de inicio es un problema menor.

Así, de esta forma, un MMDB puede ser más rápido que un OODB que tiene un contrato diferente con el disco, el mantenimiento de registros y páginas de disco. De esta manera, un OODB puede ser más lenta, incluso si todo el DB cabe en la memoria RAM y se almacena en caché correctamente, simplemente porque usted incurre en operaciones de disco fuera de las operaciones de registro durante las operaciones normales, frente a un MMDB que ocurren esas operaciones como "mantenimiento" tarea, que puede ser programado durante el tiempo de inactividad y / o tiempo de silencio.

En cuanto a si cualquiera de estos sistemas puede conocerlo necesidades reales de rendimiento, no puedo decir.

Answer 2

Los extremos traseros de las bases de datos (procesos de lector y escritor, el almacenamiento en caché, bloqueo de la gestión, los archivos de registro TXn, semántica ACID) son los mismos, por lo RDBs y OODB son en realidad muy similar aquí. La diferencia es la interfaz al programador de la aplicación. Es el modelo de datos complicado, se compone de un montón de clases con relaciones de herencia real? Entonces OO es buena. Es relativamente plana y simple? A continuación, vaya RDB. ¿Cuál es la naturaleza de las relaciones? Es puntero similar y establecer como? A continuación, vaya RDB. Es decir es más complicado, como (ordenada) lista, matriz, mapa? Entonces usted debe ir orientado a objetos. Además, no tiene una aplicación stand-alone sin la necesidad de integrar con otras aplicaciones? Entonces OO está bien. No tiene que compartir datos con otras aplicaciones (es decir, varias aplicaciones acceden a la misma base de datos)? Entonces eso es un acuerdo para romper para OO, y debe seguir con RDB. Es el esquema de la base de datos estable o qué se puede esperar que evolucione con frecuencia? BDOO son mala evolución ad esquema, por lo que si usted espera cambios frecuentes, se pega con bancos regionales de desarrollo.