¿Qué tan eficiente será la de utilizar una base de datos en memoria para almacenar millones de valores temporales?

Question

Mi aplicación almacena actualmente a millones de elementos Double para un cálculo. Estos valores son sólo valores temporales antes de ser utilizados para un algoritmo específico que se ejecuta al final del cálculo. Una vez que se realiza este cálculo, los millones de valores pueden ser descartados.

La historia completa es aquí , si necesita más detalles.

Una de las soluciones que se proponen es utilizar una base de datos en memoria.

Así que si voy con esta solución, voy a utilizar esta base de datos para almacenar mis valores en una tabla para sustituir a mi Map<String, List<Double>> actual, como:

create table CALCULATION_RESULTS_XXX (
  deal_id varchar2,
  values number
);

(una tabla por cálculo, XXX es el ID de cálculo)

Así que durante el cálculo, voy a hacer lo siguiente:

1. Cuando se inicia el cálculo, se crea la tabla CALCULATION_RESULTS_XXX.
2. Cada vez que tengo que añadir un valor, inserto un registro de esta tabla.
3. Al final del cálculo, uso el contenido de la tabla para mi algoritmo.
4. Por último, dejo caer esta tabla.

Como se explica en el otro , Actualmente, mi cálculo puede almacenar varios cientos de MB de datos en la memoria, como una lista de 30 * millón de Double se necesitan alrededor de 240 MB.

Las preguntas ahora:

1. Si voy con una base de datos en memoria, hace mi consomption memoria se reducirá?
2. ¿Cuáles son los puntos específicos que voy a tener que tener cuidado con respecto al uso de la base de datos (o creación de la tabla), la inserción de datos, etc.?
3. creo que voy a elegir H2 base de datos . ¿Cree que es la mejor opción para mis necesidades?

Answer 1

El problema es lo suficientemente simple que usted realmente necesita para simplemente darle una oportunidad y ver cómo los resultados (rendimiento) funcionan.

Ya tiene una aplicación que sólo utiliza simples estructuras en memoria. En lo personal, dado que incluso el equipo más barato de Dell viene con 1 GB de RAM +, que también podría seguir con eso. Aparte de eso, debería ser bastante fácil de sacarte en una base de datos o dos. Me considero Sleepycat Berkerly DB (que ahora es propiedad de Oracle ...), ya que no es necesario utilizar SQL y que debería ser bastante eficiente. (Hacen el soporte de Java).

Si los resultados son prometedores, entonces me considero más investigación, pero esto en realidad sólo debería tomar unos pocos días de trabajo, a lo sumo, incluyendo la evaluación comparativa.

Answer 2

Un HashMap sencilla respaldado por terracota haría mejor y permitirá a la recogida de tienda más grande que JVM memoria virtual.

bases de datos integradas, sobre todo, los basados ??en SQL queridos, se añaden complejidad y los gastos generales de su código, por lo que no vale la pena. Si realmente necesita un almacenamiento persistente con acceso aleatorio, pruebe uno de los DBs NoSQL, como CouchDB , Cassandra , Neo4j

Answer 3

No sé si va a ser más rápido, por lo que tendría que probarlo. Lo que sí quiero recomendar es hacer inserciones lotes de una lista completa cuando no se necesita de inmediato que la lista más. No Guardar valor por valor:)

Si usted es el algoritmo final se puede expresar en SQL podría también ser digno de su tiempo para hacer eso, y no cargar todas las listas de nuevo. En cualquier caso, no ponga nada como un índice o restricción sobre los valores , y preferiblemente también no permitir NULL (si es posible). El mantenimiento de los índices y las limitaciones de tiempo de costos, y permitiendo NULL también puede costar tiempo, o crear sobrecarga. deal_ids puede (y lo son) por supuesto indexado ya que son las claves principales.

Esto no es mucho pero al menos mejor que una sola respuesta abajo votado:)

Answer 4

Realmente no hay razón alguna para añadir un componente externo para hacer su programa de correr más lento. Comprimir el bloque de datos y escribirla en el archivo si tiene que manejar más de la memoria interna disponible. Una estación de trabajo ahora tiene 192 GB de RAM por lo que no puede permitirse el lujo de perder mucho tiempo en él.