Una solución de base de datos en memoria con la replicación más rápida en tiempo real

Question

Tenemos una tabla de filas de 10 mil que tiene solo 2 columnas, una clave principal y una segunda columna que conservan el estado. El problema es que necesitamos que este estado se replique en 3 ubicaciones físicas en los EE. UU. (A unas 2000 millas de distancia), casi en tiempo real o tan rápido como sea posible a través de una red. Cualquiera de las 3 ubicaciones puede actualizar el estado de una fila determinada en esta tabla, que debe replicarse casi en tiempo real en las otras 2 ubicaciones.

¿Existe alguna base de datos en memoria de fuente abierta o liviana comercial que nos pueda ayudar a lograr lo que estamos tratando de hacer? La persistencia del disco no es tan importante aquí.

Answer 1

Echa un vistazo Redis. Aquí está el Replication Howto.

Además, si decide que la base de datos no necesita estar en la memoria, solo necesita ser rápido, puede que desee considerar CouchDB. Puede hacer una replicación continua, que es esencialmente instantánea, y todos los nodos son maestros. Tiene un mecanismo bien pensado de detección y resolución de conflictos. This blog post es una gran introducción a las últimas y mejores capacidades de replicación de CouchDB.

Answer 2

Aunque no hay compatibilidad de replicación incorporada, puede usar triggers con una base de datos SQLite en memoria. Dentro del desencadenante, use un custom function para comunicar los cambios a los otros sitios.

Answer 3

Es posible que desee comprobar Altibase. Dijeron que tienen la base de datos en memoria más rápida del mundo. Dicen que son 5 a 10 veces más rápidas que la mayoría de DBMS en memoria y que también tienen una versión de prueba gratuita en el sitio.

Answer 4

Ejecuto un SQL complejo que tiene más de 6000 filas 10000 veces en mi servidor Websphere. Total de tiempos netos de ejecución son así:

  Derby (In Memory) Oracle(standard DB) SQLite (In Memory) HSQLDb (In Memory) 
      nano sec. second nano sec. second nano sec. second nano sec. second 
1. try 58000000 0,058 6149976000 6,1 1141988000 1,14 999403000 1,00 
2. try 78560000 0,078 5268477000 5,2 1182621000 1,18 1338705000 1,34 
3. try 58849000 0,058 5200898000 5,2 1133003000 1,13 2239527000 2,24 
4. try 60901000 0,06 5435216000 5,4 1205442000 1,21 1370711000 1,37 
5. try 58798000 0,058 6501929000 6,5 1186734000 1,19 1001800000 1,00 
6. try 62928000 0,062 5913053000 5,9 1224470000 1,22 1066736000 1,07 
7. try 71171000 0,071 5111207000 5,1 1200769000 1,20 1304524000 1,30 
8. try 66913000 0,066 5517989000 5,5 1173495000 1,17 1299230000 1,30 
9. try 58777000 0,058 7209555000 7,2 1179013000 1,18 1031795000 1,03 
10. try 75299000 0,075 5356514000 5,3 1182715000 1,18 1368461000 1,37 
average 65019600 0,064 5766481400 5,7 1181025000 1,18 1302089200 1,30 

obviamente comparar Derby, SQLite y HSQLDB. Oracle no está en la memoria db. Pero pongo su resultado en la tabla porque muestra la diferencia de velocidad entre a en la memoria db y la db normal.

PD: En SQLite y HSQLDB el resultado no es estable. Así que elijo 10 resultados estables en 100 intentos. A veces HSQLDB es más rápido que SQLite. Creo que el rendimiento de ellos es el mismo.