Archivos mapeados en memoria: pros y contras?

Question

Necesito compartir datos entre dos aplicaciones Java que se ejecutan en la misma máquina (dos JVM diferentes). Preciso que los datos que se compartirán son grandes (alrededor de 7 GB). Las aplicaciones deben acceder a los datos muy rápido porque tienen que responder consultas entrantes a una velocidad muy alta. No quiero que las aplicaciones tengan una copia de los datos.

He visto que una opción es utilizar archivos mapeados en memoria. La aplicación A obtiene los datos de algún lugar (digamos una base de datos) y los almacena en archivos. Entonces la aplicación B puede acceder a estos archivos usando java.nio. No sé exactamente cómo funcionan los archivos mapeados en memoria, solo sé que los datos están almacenados en un archivo y que este archivo (o parte de él) está asignado a una región de la memoria (¿memoria virtual?). Entonces, las dos aplicaciones pueden leer y escribir los datos en la memoria y los cambios son automáticamente (¿supongo?) Comprometidos con el archivo. Tampoco sé si hay un tamaño máximo para que un archivo se mapee completamente en la memoria.

Mi primera pregunta es cuáles son las diferentes posibilidades para que dos aplicaciones compartan datos en este escenario (quiero decir teniendo en cuenta que la cantidad de datos es muy grande y que el acceso a estos datos debe ser muy rápido). Preciso que esta pregunta no está relacionada con la E/S mapeada en memoria, solo para saber cuáles son las otras formas de resolver el mismo problema.

Mi segunda pregunta es ¿cuáles son los pros y los contras del uso de archivos mapeados en memoria?

Gracias

Answer 1

Mi primera pregunta es ¿cuáles son las diferentes posibilidades para dos aplicaciones compartan datos?

Como señala S. Lott, hay una gran cantidad de mecanismos:

• nivel de sistema operativo message queues
• nivel de sistema operativo POSIX shared memory segments (persisten después de la muerte de proceso)
• nivel de sistema operativo memory mappings (podría ser anónimo o respaldado por archivos)
• OS-level anonymous pipes (unidireccional)
• nivel de sistema operativo named pipes (unidireccional)
• nivel de sistema operativo sockets (bidireccional) - si AF_UNIX o AF_INET o AF_INET6
• nivel de sistema operativo shared global memory - adecuado para programas multihilo
• Almacenamiento de datos en archivos
• a nivel de aplicación message queues
• a nivel de aplicación blackboard-style tuplespaces
• Application-nivel key/value stores
• nivel de aplicación remote procedure call frameworks-many are available
• nivel de aplicación web-based frameworks

Mi segunda pregunta es ¿cuáles son los pros y los contras del uso de archivos asignados a la memoria?

Pros:

• muy rápido - dependiendo de cómo se accede a los datos, potencialmente zero-copy mecanismos pueden ser utilizados para operar directamente sobre los datos sin penalizaciones de velocidad. Se debe tener cuidado para actualizar objetos de una manera consistente.
• debe ser muy portable - disponible en los sistemas Unix para probablemente 25 años (más o menos), and apparently Windows has mechanisms too.

Contras:

• compartir Sistema sencillo. Si desea distribuir su aplicación en varias máquinas, la memoria compartida no es una gran opción. Distributed shared memory systems are available, pero se parecen mucho a la interfaz incorrecta de mi forma de pensar.
• Incluso en un solo sistema, si la memoria se encuentra en un solo NUMA node pero necesitaba ser visitada por los procesadores de múltiples nodos, las solicitudes inter-nodo puede procesamiento significativamente lento en comparación con dar a cada nodo de su propio segmento de la memoria.
• No puede simplemente almacenar punteros: todo debe almacenarse como desplazamientos a las direcciones base, ya que la memoria se puede mapear en diferentes ubicaciones en diferentes procesos. No tengo idea de lo que esto significa para los objetos Java, aunque presumiblemente alguien inteligente hizo todo lo posible para que sea transparente para los programadores de Java. Si no está utilizando los mecanismos provistos, entonces probablemente deba hacer el trabajo usted mismo. (Sin punteros reales en Java, quizás esto no sea muy oneroso.)
• La actualización de objetos de manera consistente ha demostrado ser muy difícil. En su lugar, pasar immutable objects en sistemas de paso de mensajes generalmente genera programas con menos errores de concurrencia. (La programación concurrente en Erlang se siente muy natural y directa. La programación concurrente en más imperative languages tiende a presentar una gran cantidad de nuevos controles de concurrencia: semaphores, mutexes, spinlocks, monitors).
archivos

Answer 2

memoria mapeada suena como un dolor de cabeza. Una opción simple y menos propensa a errores sería usar una base de datos compartida con un caché de cluster aware. De esta forma, solo las escrituras se transfieren a la base de datos y las lecturas se pueden enviar desde la memoria caché.

Como un ejemplo de cómo hacer esto en hibernación ver http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-cache