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

Question

Tenemos una mesa de 10 mil fila que tiene sólo 2 columnas, una clave principal y una segunda columna que mantener el estado. El problema es que necesitamos este estado para ser replicado en 3 lugares físicos en los EE.UU. (alrededor de 2000 millas de distancia), casi en tiempo real o tan rápido como sea prácticamente posible a través de una red. Cualquiera de los 3 lugares se puede actualizar el estado de una fila dada en esta tabla que debe ser replicado en tiempo casi real a los otros 2 lugares.

¿Hay algún código abierto o peso ligero base de datos comercial en memoria que podría ayudar a lograr lo que estamos tratando de hacer. la persistencia de disco no es tan importante en este caso.

Answer 1

Redis . Aquí está la replicación Howto .

Además, si usted decide que el PP no necesita absolutamente ser en memoria, sólo tiene que ser rápido, es posible que desee considerar la CouchDB . Se puede hacer la replicación continua, que es esencialmente instantáneo, y todos los nodos son maestros. Tiene una detección de conflictos bien pensada y el mecanismo de resolución. Esta entrada de blog es una gran introducción a las últimas y mejores capacidades de replicación CouchDB.

Answer 2

Aunque no hay soporte de replicación incorporada, puede utilizar desencadenantes con una de -Memoria SQLite base de datos. Dentro del disparador, utilizar un función personalizada para comunicar los cambios a los otros sitios.

Answer 3

Es posible que desee echa un vistazo a Altibase . Ellos dijeron que no tienen base de datos en la memoria más rápida del mundo. Dicen que son de 5 a 10 veces más rápido que la mayoría de los DBMS en memoria y también tienen una versión de prueba en el sitio.

Answer 4

Me ejecutar un SQL complejo que cuenta con más de 6000 filas 10.000 veces en mi Websphere Application Server. 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

Yo, obviamente, comparar Derby, SQLite y HSQLDB. Oracle no es una db en la memoria. Pero lo puse de resultado de mesa porque para mostrar una diferencia de velocidad entre la memoria y en db db normal.

PS: En SQLite y resultado HSQLDB no son estables. Así que elegir 10 resultados estables en 100 intentarlo. A veces es más rápido que HSQLDB SQLite. Creo que ellos son el rendimiento mismo.