¿Cuándo debería considerar usar una base de datos en la memoria y cuál es el problema a tener en cuenta?

Question

que era sólo piensa que ahora es común tener suficiente memoria RAM en el servidor de base de datos para almacenar en caché la base de datos completa ¿por qué el especialista en memory database (por ejemplo TimesTen, consulta Wikipedia page) que estaban de moda hace unos años no se siendo usado más?

Parece que a medida que pasa el tiempo, ninguna base de datos basada en disco se utiliza con menos frecuencia, por ejemplo, la mayoría de las aplicaciones ahora se basan en bases de datos racionales convencionales. Hubiera esperado lo contrario ya que la RAM se está acercando a ser gratuita para muchos servidores.

estoy pidiendo esto, como acabo de leer sobre la pila de desbordamiento de la arquitectura y la página dice

Esto es significativo porque la base de datos Pila de desbordamiento es casi por completo en la memoria RAM y la une todavía un costo muy alto.

Pero no creo que esto suponga un problema si se usan "punteros" y "colecciones" en lugar del btree normal. Btree es muy inteligente para sortear los límites de la velocidad de acceso al disco, por ejemplo, intercambian el uso de la CPU para reducir el uso del disco. Sin embargo, ahora tenemos tan coincidir ram.

Pero todavía tenemos la base de datos, como hacer su propio

• bloqueo
• detección de estancamiento
• el registro de transacciones
• recuperando
• Etc

es muy difícil.

@ S.Lott, dado que todos pasamos tanto tiempo eligiendo índices, evitando uniones e investigando los problemas de rendimiento de la base de datos. Debe haber una mejor manera. Hace unos años nos dijeron que "en las bases de datos de la memoria" era la mejor manera. Entonces, antes de saltar a usar uno, me gustaría saber por qué otras personas no los usan más.

(soy poco probable que utilice TimesTen mismo, ya que tiene un precio alto ($41,500.00/Processor) y no me gusta hablar con la gente de ventas de Oracle - Yo prefiero pasar mi tiempo de escribir código.)

Ver también:

• Alternative to the TimesTen in memory database
• Has anyone published a detailed comparison between different in-memory RDBMSs?

Actualización:

hice esta pregunta hace un tiempo LARGO, en estos días de Microsoft SQL Server tienen "In-Memory OLTP" que es un motor de base de datos de la memoria optimizada integrado en el motor de SQL Server. No es barato, pero parece ser muy rápido para algunas cargas de trabajo.

Answer 1

Lo más probable es que simplemente no existan productos maduros de bases de datos de memoria que puedan usarse como un reemplazo completo para una base de datos clásica.

La base de datos relacional es un concepto muy antiguo. Aunque hubo muchos enfoques para avanzar y desarrollar nuevas tecnologías, por ejemplo. bases de datos orientadas a objetos, las bases de datos relacionales realmente no cambiaron sus conceptos. No espere que las cosas cambien demasiado rápido, ya que las bases de datos no cambiaron mucho en los últimos diez o quince años o incluso más.

Creo que el desarrollo de tecnologías no es tan rápido como uno podría creer. Lleva décadas madurar y establecer nuevos conceptos. En primer lugar en las tecnologías de bases de datos, donde la madurez es mucho más importante que cualquier otra cosa.

En diez o veinte años, las bases de datos probablemente ya no sean las mismas que en la actualidad. Si las bases de datos en memoria son el futuro, nadie puede decir esto hoy, solo necesitan un poco más de tiempo para desarrollarse.

Answer 2

La tendencia parece ser almacenar en caché de manera agresiva y utilizar la base de datos para llenar el caché. Independientemente de dónde viva la base de datos, las uniones siguen siendo costosas, por lo que la preferencia parece ser hacer la unión una vez y almacenar en caché el resultado en algo como Memcached o Velocity.

Todavía hay bases de datos en memoria y se usan, pero depende del contexto en el que desea usarlas. SQLite, por ejemplo, se usa a menudo como una base de datos en memoria cuando se prueban capas de datos.

Answer 3

Bueno, bases de datos en memoria por lo general carecen de la D (durabilidad) en ACID (atomicidad, coherencia, aislamiento, durabilidad) por su propia naturaleza. Esto se puede superar en cierta medida con enfoques "híbridos", sin embargo, en algún momento algo (ya sea los datos mismos o un registro de transacciones) debe persistir en algún lugar para proporcionar el aspecto de durabilidad. En general, esto puede ralentizar el rendimiento o introducir otras propiedades no deseables en una solución de base de datos en memoria

En contraste, la mayoría de los RDBMS de hoy tienen el complemento completo de ACID, además de tener muchas décadas de desarrollo detrás de ellos. Esto ha resultado en sistemas de bases de datos basados ​​en disco que son muy eficientes, especialmente con los muchos años de mejoras y optimizaciones que el sistema RDBMS moderno ha visto (su ejemplo BTree es solo uno de muchos).

Otro factor es nuestra capacidad como desarrolladores de aplicaciones para reducir la carga en la base de datos mediante mecanismos tales como caching, apretando de ese modo mucho más percibida el rendimiento de la capa de datos de una aplicación. De hecho, el almacenamiento en caché ha tenido un gran desarrollo en los últimos años, siendo el caché distribuido el más común hoy en día (basta con ver el número users of memcached, por ejemplo).

Irónicamente, los sistemas de caché de hoy en día están, de muchas maneras, transformándose lentamente en algo parecido a un verdadero sistema de base de datos en memoria. Las bases de datos en memoria, como las bases de datos orientadas a objetos, son en gran medida los "nuevos niños en el bloque", por lo que será interesante ver dónde va todo esto a tiempo. Oracle ahora adquirió TimesTen y, de acuerdo con this wikipedia article, Microsoft está buscando introducirse en el mercado de la base de datos en memoria muy pronto. Son dos "grandes jugadores" modernos en el campo RDBMS tradicional que toman en serio los sistemas de bases de datos de memoria.

Answer 4

La razón más importante es la cultura de la carga y el bajo nivel de conocimiento en TI.La mayoría de las aplicaciones funcionan lo suficientemente bien sea cual sea la solución de persistencia utilizada, y como las computadoras son cada vez más rápidas cada año, no hay suficientes personas que sientan el dolor y sean capaces de identificar el problema.

Microsoft y Oracle ganan demasiado dinero con sus productos de bases de datos para hacer que (políticamente) les sea posible encontrar mejores enfoques.

Los costes de desarrollo de utilizar una base de datos relacional no se hacen transparentes, por lo que la dirección no tiene idea de que existe un problema, y ​​mucho menos una solución.

Answer 5

Nadie realmente respondió la pregunta "¿Cuándo debería considerar usar una base de datos en memoria y cuál es el problema a tener en cuenta?" así que lo intentaré.

Debe tener en cuenta una base de datos en memoria si: 1. El sistema de destino tiene los datos a manejar, pero no hay medios persistentes 2. El requisito de rendimiento simplemente no puede cumplir con una base de datos persistente

Para # 1 , piense en la Guía de TV en su descodificador (STB). Los STB de gama baja (es decir, aquellos que no tienen capacidad de DVR) no tienen almacenamiento persistente y no necesitan almacenamiento persistente. Pero la base de datos para una guía de TV de 400 canales y 14 días no es trivial. También hay un requisito de rendimiento aquí, porque los datos llegan desde el carrusel del transpondedor a alta velocidad y es un caso de "capturarlo o esperar hasta que el carrusel vuelva a aparecer". Pero no hay necesidad de persistencia. Todos hemos visto esto; cuando pierde energía en su hogar, cuando vuelve a encenderse, la Guía de TV dice "estará disponible en breve" porque se está aprovisionando desde el transpondedor o la cabecera del cable. Los enrutadores de red comparten las mismas características: no hay almacenamiento persistente, es necesario que sea rápido, y la base de datos se puede aprovisionar desde una fuente externa (enrutadores pares en la red, en este caso, para volver a llenar la tabla de enrutamiento).

Existen innumerables ejemplos de # 2: orientación en tiempo real en sistemas militares, sistemas de comercio de alta frecuencia y más.

En cuanto a la segunda parte de la pregunta, "tema a tener en cuenta": hay muchos.

Asegúrese de que está evaluando una verdadera base de datos en memoria si necesita el rendimiento que solo puede ofrecer una base de datos en memoria. Caché de una base de datos persistente no es lo mismo. Lanzar una base de datos persistente en una unidad RAM no es lo mismo. El uso de una base de datos en memoria que inherentemente hace el registro de transacciones (como TimesTen) no es el mismo (incluso si se registra en/dev/null).

Asegúrese de que está evaluando un sistema de base de datos, y no simplemente un caché (por ejemplo, Memcache). Un sistema de base de datos tendrá soporte para transacciones con las propiedades ACID, múltiples opciones de indexación, soporte de acceso concurrente y más.

Acerca de ACID: los sistemas de base de datos en memoria no carecen de la 'D' (durabilidad). Simplemente tiene que tomarse en contexto. Las transacciones en una base de datos persistente son duraderas solo mientras el medio en el que está almacenado sea duradero. Lo mismo es cierto para las bases de datos en memoria. En cualquier caso, si te preocupa la durabilidad, es mejor que tengas una copia de seguridad.

Answer 6

Esta es también una opción: http://www.memsql.com/

No he utilizado personalmente, pero se supone que debe estar en la línea de una gota en el reemplazo para MySQL en memoria.

Answer 7

Diversas versiones portátiles de SQL, que funcionarán con la misma eficacia, diseñadas principalmente para dispositivos móviles.

SQLite

SQL Server Compact Edition

Estos son sólo grandes jugadores otras opciones pueden estar allí, pero los grandes jugadores manejar los requerimientos mínimos con la liberación de la misma .. :)

y la base de datos de la memoria, usted tiene Haga una copia de seguridad de los datos continuamente si se produce una fluctuación o corte de energía. Puede perder todo el grupo. como en otro que se manejará como su memoria secundaria (HDD) y las posibilidades de pérdida serán del 10% en comparación con la memoria DB.

espero que esto puede ayudar :)

Answer 8

El caso de uso más típico de una base de datos es la persistencia, lo que hace que la mayoría de las bases de datos en memoria inadecuada. Una razón popular para usar una base de datos en memoria es para realizar pruebas. Pero esto requiere que uses una base de datos que se puede configurar tanto en la memoria como en otra cosa.

Las elecciones más populares en esta área parecen ser RavenDB para desarrolladores de .Net y desarrolladores de OrientDB para Java. Porque ambos pueden funcionar como bases de datos en memoria, y "algo más" dependiendo de la configuración, de modo que puede usar uno u otro según su configuración (app.config en .Net, Maven o Ant settings en Java).

Answer 9

Las necesidades de procesamiento de datos son cada vez más complejas y el ecosistema del producto está evolucionando para satisfacer estas nuevas necesidades. Los RDBMS basados ​​en disco, la memoria caché en memoria y las bases de datos en memoria se utilizan para satisfacer diferentes necesidades. Debe ir con lo que se ajuste a sus necesidades:

RDBMS tradicional: Su clúster MySQL es lo suficientemente rápido, fácil de mantener y le gusta tener la confiabilidad de cumplir con ACID.

Cahorna distribuida en memoria: Su aplicación necesita leer y escribir rápidamente sin preocuparse demasiado por la coherencia o las transacciones complejas.

en memoria RDBMS:

1. (velocidad): Su aplicación necesita para procesar datos/solicitudes más rápido que su basado en disco lata base de datos.
2. (Complejidad): Necesita realizar lecturas y escrituras transaccionales complejas con uniones y agregaciones y desea utilizar el poder de SQL.
3. (Escalabilidad): Necesita escalar su base de datos horizontalmente sin tiempo de inactividad.
4. (Maintainable): Necesita la base de datos para proporcionar alta disponibilidad, replicación, equilibrio de carga y recuperación ante desastres sin agregar a sus tareas de mantenimiento.
5. (Advertencia): sus datos deben caber en la memoria (generalmente en terabytes).