Recomendaciones para una base de datos en memoria frente a estructuras de datos seguras para hilos

Question

TLDR: ¿Cuáles son las ventajas y desventajas de usar una base de datos en memoria frente a bloqueos y estructuras de datos concurrentes?

Actualmente estoy trabajando en una aplicación que tiene muchas pantallas (posiblemente remotas) que recopilan datos en vivo de múltiples fuentes de datos y los muestra en pantalla en tiempo real. Uno de los otros desarrolladores sugirió el uso de una base de datos en memoria en lugar de hacerlo de la manera estándar en que se comportan nuestros otros sistemas, que consiste en utilizar hashps, colas, matrices y otros objetos concurrentes para almacenar los objetos gráficos y manejarlos de forma segura. bloquea si es necesario. Su argumento es que el DB reducirá la necesidad de preocuparse por la simultaneidad, ya que manejará bloqueos de lectura/escritura automáticamente, y también el DB ofrecerá una manera más fácil de estructurar los datos en tantas tablas como necesitemos en lugar de tener crear hashps de hasmaps de listas, etc. y hacer un seguimiento de todo.

No tengo mucha experiencia DB, así que les pregunto a los compañeros SO qué experiencias han tenido y cuáles son los pros & contras de insertar el DB en el sistema?

Answer 1

Bueno, una desventaja importante sería la falta de correspondencia entre Java y un DB. Eso es un gran dolor de cabeza si no lo necesitas. También sería mucho más lento para un acceso realmente simple. Por otro lado, los beneficios serían las transacciones y la persistencia en el sistema de archivos en caso de una falla. Además, según sus necesidades, permite consultas de una manera que podría ser difícil de hacer con una estructura de datos Java común.

Para algo intermedio, me gustaría echar un vistazo a Neo4j. Es una base de datos de gráficos pura de Java. Esto significa que es fácilmente integrable, maneja la concurrencia y las transacciones, escala bien y no tiene todos los problemas de desajuste que tienen los DB relacionales.

Actualizado Si su estructura de datos es bastante simple - un mapa de las listas, mapa de mapas, algo así, es probable que pueda salirse con cualquiera de las colecciones concurrentes en el JDK o Google Collections, pero mucho más allá de eso, y es probable que se encuentre recreando una base de datos en memoria. Y si sus restricciones de consulta son remotamente difíciles, tendrá que implementar todas esas instalaciones usted mismo. Y luego tendrá que asegurarse de que funcionen al mismo tiempo, etc. Si esto requiere una complejidad o escala seria (grandes conjuntos de datos), definitivamente no lanzaría el suyo a menos que realmente quiera comprometerse con él.

Si decide ir con una base de datos incrustada hay bastantes opciones. Es posible que desee comenzar considerando si desea o no ir a la ruta SQL o NoSQL. A menos que vea beneficios reales para SQL, creo que también aumentaría en gran medida la complejidad de su aplicación. Hibernate es probablemente la ruta más fácil con el SQL menos real, pero sigue siendo un dolor de cabeza. Lo he hecho con Derby sin problemas serios, pero aún no es sencillo. Puede intentar db4o, que es una base de datos de objetos que se puede incrustar y no requiere asignación. This is a good overview. Como he dicho antes, si fuera yo si probara con Neo4j, podría ser solo porque quiero jugar con cosas nuevas y brillantes;) Solo lo veo como una biblioteca muy transparente que tiene sentido. Hibernate/SQL y db4o solo parecen agitar demasiado la mano para sentirse livianos.

Answer 2

No me queda claro por qué cree que una base de datos en memoria no puede ser segura para subprocesos.

¿Por qué no miras JDO y DataNucleus? Tienen una gran cantidad de almacenes de datos diferentes donde puede conectar lo que su proveedor de persistencia es en tiempo de ejecución como un paso de configuración. El código de la aplicación depende de un ORM pero dicho ORM podría estar conectado a un RDBMS, DB40, NeoDatis, LDAP, etc. Si un servidor no funciona para usted, cambie a otro.

Answer 3

Estuve trabajando para un proyecto que usa Oracle TimesTen. Esto fue a principios de 2006 cuando recién se lanzó Java 5 y las clases java.util.concurrent eran apenas conocidas. El sistema que hemos desarrollado tenía requisitos de escalabilidad y rendimiento razonablemente grandes (era uno de los principales cuadros de telecomunicaciones para mensajes SMS/MMS).

En pocas palabras, el razonamiento para TimesTen fue justo: "externalicemos nuestros problemas de simultaneidad/escalabilidad a otra persona y nos concentremos en nuestro dominio comercial" y tuvo perfecto sentido en ese momento. Pero esto fue en el 2006. No creo que tal decisión se tome hoy.

La concurrencia es difícil, pero también lo es el manejo de bases de datos en memoria. Librándote de los problemas de concurrencia, deberías convertirte en un experto en el mundo de las bases de datos en memoria. Ajuste fino TimesTen para la replicación es difícil (tuvimos que contratar un consultor profesional de Oracle para hacer esto). La (s) licencia (s) no son gratuitas. También debe preocuparse por capas adicionales que no sean de código abierto o que estén escritas en un idioma diferente al que usted entiende.

Pero es realmente difícil juzgar sin conocer su experiencia, presupuesto, requisitos de tiempo, etc. Haga una compra, dedique un tiempo a buscar marcos de simultaneidad de concurrencia (como http://akkasource.org/) ... y déjenos saber lo que has decidido;)

Answer 4

Puedes usar algo como Space4J y obtener los beneficios de una colección como interfaz y una base de datos en memoria. En el uso práctico, algo tan básico como una Colección es una base de datos en la memoria sin índice. Una lista es una base de datos en memoria con un único índice int. Un mapa es una base de datos en la memoria con un único índice indexado de tipo T y sin concurrencia a menos que esté sincronizado o una implementación java.util.concurrency. *.

Answer 5

A continuación hay algunas preguntas que podrían facilitar una decisión.

• Consultas: ¿necesita consultar/reproyectar/agregar sus datos en diferentes formas?
• Transacciones: ¿alguna vez necesita deshacer los datos agregados?
• Persistencia: ¿solo necesita presentar los datos recopilados o también necesita almacenarlos de alguna manera?
• Escalabilidad: ¿sus datos siempre caben en la memoria?
• Rendimiento: ¿qué tan rápido debería ser?