Файлы с отображением в памяти: плюсы и минусы?

Question

Мне нужно обмениваться данными между двумя приложениями Java, работающими на одной машине (две разные JVM).Я уточняю, что данные для обмена большие (около 7 ГБ).Приложения должны получать доступ к данным очень быстро, потому что они должны отвечать на входящие запросы с очень высокой скоростью.Я не хочу, чтобы приложения хранили каждую копию данных.

Я видел, что одним из вариантов является использование отображенных в памяти файлов.Приложение A получает данные откуда-то (скажем, из базы данных) и сохраняет их в файлах.Тогда приложение B может получить доступ к этим файлам, используя java.nio.Я не знаю точно, как работают файлы с отображением в памяти, я знаю только то, что данные хранятся в файле и этот файл (или его часть) отображается в область памяти (виртуальная память?).Итак, два приложения могут читать и записывать данные в память, и изменения автоматически (я полагаю?) Фиксируются в файле.Я также не знаю, существует ли максимальный размер файла, который будет полностью отображаться в памяти.

Мой первый вопрос: каковы разные возможности для двух приложений для обмена данными в этом сценарии (я имею в видупринять во внимание, что объем данных очень велик и что доступ к этим данным должен быть очень быстрым)?Я уточняю, что этот вопрос не связан с вводом-выводом, отображаемым в память, а просто для того, чтобы узнать, каковы другие способы решения этой проблемы.

Мой второй вопрос - каковы плюсы и минусы использования памятисопоставленные файлы?

Спасибо

Answer 1

Мой первый вопрос: каковы разные возможности для обмена данными между двумя приложениями?

Как указывает С.Лотт, существует лот механизмов:

• на уровне ОС очереди сообщений
• на уровне ОС сегменты разделяемой памяти POSIX (сохраняются после смерти процесса)
• Уровень ОС Отображение памяти (может быть анонимным или с файловой поддержкой)
• Уровень ОС Анонимные каналы (однонаправленный)
• Уровень ОС именованные каналы (однонаправленные)
• уровень ОС розетки (двунаправленные) - AF_UNIX или AF_INET или AF_INET6
• Уровень ОС общая глобальная память - подходит для многопоточных программ
• Хранение данных в файлах
• Уровень приложения очереди сообщений
• Уровень приложения Пространства кортежей в стиле доски
• Уровень приложения хранилища ключей / значений
• Уровень приложения инфраструктуры удаленного вызова процедур - доступно много
• Уровень приложения веб-платформы

Мой второй вопрос: каковы плюсы и минусы использования файлов с отображенной памятью?

Плюсы:

• очень быстро - в зависимостив зависимости от того, как вы получаете доступ к данным, потенциально можно использовать механизмы нулевого копирования для непосредственного управления данными без потери скорости.Необходимо соблюдать осторожность при обновлении объектов согласованным образом .
• должно быть очень переносимым - доступно в системах Unix, вероятно, на 25 лет (дать или взять), и, очевидно, Windowsтакже есть механизмы .

Минусы:

• Совместное использование в одной системе.Если вы хотите распределить свое приложение по нескольким машинам, разделяемая память не является отличным вариантом. Доступны распределенные системы с общей памятью , но они очень похожи на неправильный интерфейс моего мышления.
• Даже в одной системе, если память расположена в одной Узел NUMA , но требуется, чтобы процессоры обращались к нему из нескольких узлов, запросы между узлами могут значительно замедлить обработку по сравнению с предоставлением каждому узлу отдельного сегмента памяти.
• Нельзя просто сохранитьуказатели - все должно храниться как смещений к базовым адресам, поскольку память может отображаться в разных местах в разных процессах.Я понятия не имею, что это означает для объектов Java, хотя, вероятно, кто-то умный сделал все возможное, чтобы сделать его прозрачным для Java-программистов.Если вы не используете предоставленные им механизмы, вы, вероятно, должны выполнить работу самостоятельно.(Без фактических указателей в Java, возможно, это не очень обременительно.)
• Последовательное обновление объектов оказалось очень трудным.Передача неизменяемых объектов в системах передачи сообщений обычно приводит к программам с меньшим количеством ошибок параллелизма.(Параллельное программирование в Erlang кажется очень естественным и простым. Параллельное программирование на более императивных языках имеет тенденцию вводить огромную кучу новых элементов управления параллелизмом: семафоров , мьютексы , спин-блокировки , мониторы ).

Answer 2

Файлы с отображением в памяти звучат как головная боль. Простой вариант и менее подверженный ошибкам будет использовать общую базу данных с кластерным кэшем. Таким образом, только записи попадают в базу данных, и чтение может быть передано из кэша.

В качестве примера того, как это сделать в спящем режиме, см. http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-cache