ventajas valor relacional funciona ejemplos ejemplo desventajas datos como clave caracteristicas bases java database web-applications nosql embedded-database

java - valor - redis ventajas y desventajas



¿Qué base de datos incrustada está escrita en Java para un simple almacén de clave/valor? (7)

Hace poco hice una pregunta sobre Neo4j, en la que trabajé y que me parece bien. Es incorporable y está escrito en Java y no hay (también) muchas dependencias.

Sin embargo, es un DB de gráficos y no sé si es una buena idea o no usarlo como un simple almacén de clave / valor.

Básicamente tengo un mapa grande, que en Java se vería así:

Map<Integer,Map<String,String>>

Tengo unas decenas de millones de entradas en el mapa principal y cada entrada contiene un mapa de propiedades / valores. El mapa "interno" es relativamente pequeño: alrededor de 20 entradas.

Necesito una forma de mantener ese mapa desde la ejecución de la aplicación web a la otra.

Usando Neo4j, lo que hice es crear un nodo para cada ID (entero) y luego poner una propiedad para cada entrada dentro del mapa interno. Desde mis primeras pruebas parece funcionar, pero no estoy seguro de que sea una buena manera de proceder.

¿Qué base de datos incrustable, escrita en Java, usaría?

Los requisitos son:

  • escrito en Java

  • empotrable (por lo que nada es demasiado grande)

  • no SQL (*)

  • fuente abierta

  • fácil de realizar copias de seguridad (necesito poder hacer copias de seguridad "en vivo", mientras el servidor se está ejecutando)

Mi terminología también puede estar un poco equivocada, así que siéntete libre de ayudarme / corregirme. Para mi "mapa de mapas", el mejor ajuste sería un par de clave / valor, ¿no?

Estoy un poco perdido como la diferencia entre los pares de clave / valor DB, DB de documento, tablas grandes, DB de gráfico, etc.

También me gustaría si es una buena idea usar una base de datos gráfica como Neo4J para mi necesidad (creo que el rendimiento realmente no va a ser un problema, ya que tendré una cantidad relativamente pequeña de entradas).

Por supuesto, yo mismo podría persistir en mi mapa de mapas, pero realmente no quiero reinventar ninguna rueda aquí. Quiero reutilizar un DB probado y probado ...

(*) La razón por la que no quiero SQL es porque siempre tendré este "mapa de mapas" y que el mapa interno evolucionará constantemente, por lo que no quiero algo demasiado estructurado.

Checkout www.jsondb.io

Esta es una base de datos ligera java, que se puede incrustar, que almacena sus datos como archivos, lo que facilita la copia de seguridad

Para su caso de uso, recomendaría MapDB ( http://www.mapdb.org )

Se ajusta a sus necesidades:

  • escrito en Java
  • Embebible - un solo frasco sin dependencias
  • no SQL: le proporciona mapas que se conservan en el disco
  • código abierto (licencia Apache 2)
  • fácil de copia de seguridad (pocos archivos)

y tiene otras características interesantes como transacciones, concurrencia y rendimiento.

Tarde a la parte pero puedes usar Tayzgrid. Su código abierto y su caché en proceso se pueden incrustar en su aplicación. Básicamente es un almacén de valores In Memory Data Grid o In Memory Key, pero también tiene la capacidad que usted desea, es decir, ser un simple almacén de valores integrado de procesos.

Usted podría simplemente quedarse con un archivo XML o JSON. Ninguno de los dos requiere un esquema y es bastante fácil ir y venir entre el disco y la memoria, especialmente si el rendimiento realmente no importa demasiado. (por ejemplo, solo carga configuraciones de vez en cuando)

La ventaja es que XML y JSON son muy simples y manejan los mapas bastante bien.

También tiene una carga de dependencia mucho más ligera en su aplicación. Todo un sistema de tipo de base de datos incorporado es bastante pesado si solo está persistiendo / no manteniendo una estructura de big data cuando es necesario y no está utilizando ninguna de las consultas o capacidades similares que la mayoría de las soluciones incorporadas agregarán.

Para cumplir con sus requisitos, está integrado en Java en su mayor parte, es fácil de realizar copias de seguridad, ya que es solo un archivo, altamente incrustable, de código abierto, y no de SQL. XML puede ser un poco detallado y difícil de manejar a veces, pero es un dominio bien conocido y tiene herramientas muy ricas que lo rodean para que pueda manejarlo de manera externa a su aplicación si es necesario.

Chronicle-Map es un nuevo jugador agradable en este campo.

  • Se encuentra fuera del montón (con capacidad de persistir en el disco por medio de archivos asignados en memoria) Implementación del Map
  • Súper rápido: sostiene millones de consultas / actualizaciones por segundo, es decir, cada consulta tiene una latencia de un microsegundo en promedio
  • Admite actualizaciones simultáneas (se supone que son un reemplazo ConcurrentHashMap de ConcurrentHashMap )
  • Soporte especial de los mapas de propiedades que mencionó, si el conjunto de propiedades está fijo dentro de la colección: permite actualizar propiedades específicas del valor sin ninguna serialización / deserialización del valor total (20 campos). Esta característica se denomina generación de valor de datos en el proyecto Chronicle / Lang .
  • Y muchos más...