Una solución de base de datos en memoria con la replicación más rápida en tiempo real [cerrada]
-
22-09-2019 - |
Pregunta
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.
Solución
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.
Otros consejos
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.
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.
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.