Я думаю, что ваш дизайн звучит разумно.Однако есть несколько вещей, которые нужно иметь в виду.Во-первых, вы уверены, что добавление дополнительной сложности оправдано?То есть, является ли снижение производительности записью в кучу файлов и последующим их чтением в важном узком месте?Если потерянное время не важно, я настоятельно рекомендую вам не вносить эти изменения.Вы бы просто увеличили сложность системы без особой выгоды.Я предполагаю, что вы уже думали об этом, но на всякий случай я не думал, что я опубликую это здесь.
Во-вторых, вы рассматривали вопрос об использовании отображенных в память файлов через MappedByteBuffer?Если вы имеете дело с огромными объектами, которые превышают пространство кучи Java и готовы приложить немного усилий, вы можете подумать о том, чтобы спроектировать объекты так, чтобы они сохранялись в файлах с отображением в памяти.Вы можете сделать это, создав класс-оболочку, которая по сути является тонкой оболочкой, которая преобразует запросы в операции в отображенном байтовом буфере.Например, если вы хотите сохранить список запросов, вы можете сделать это, создав объект, который использует MappedByteBuffer для хранения списка строк на диске.Например, строки могут храниться разделенными символами новой строки или нулевыми терминаторами.Затем вы могли бы перебирать строки, проходя через байты файла и повторно их гидрируя.Преимущество этого подхода состоит в том, что он снимает сложность кэширования с операционной системой, которая десятилетиями настраивалась на производительность (при условии, что вы используете основную ОС!) Для эффективного решения этого случая.Однажды я работал над проектом на Java, где я создал фреймворк для автоматизации этого, и во многих случаях он работал замечательно.Это определенно немного трудоемкая кривая обучения, но как только она заработает, вы сможете хранить в кучи Java больше данных, чем могли бы раньше.По сути, это делает то, что вы предложили выше, за исключением того, что он торгует с некоторой предварительной сложностью реализации, чтобы позволить ОС обрабатывать все кэширование.
В-третьих, есть ли способ объединить проходы (1) и (2))?То есть, вы могли бы сгенерировать XML-файл одновременно с базой данных?Из вашего описания я предполагаю, что проблема в том, что вы не можете сгенерировать XML, пока все записи не будут готовы.Однако вам может потребоваться создать на диске несколько разных файлов, каждый из которых хранит объекты одного типа в сериализованном формате XML, и в конце прохода можно использовать стандартную утилиту командной строки, такую как cat, чтобы объединить их все вместе.,Поскольку это можно сделать, просто выполнив массовую байтовую конкатенацию, а не анализируя содержимое базы данных, это может быть намного быстрее (и проще в реализации), чем предложенный вами подход.Если файлы все еще горячие в кэше ОС (что, вероятно, и есть, поскольку вы только что писали в них), это может быть на самом деле быстрее, чем ваш текущий подход.
В-четвертых, если вам важна производительность,Вы рассматривали распараллеливание вашего кода?Учитывая потрясающе огромные файлы для обработки, вы можете разбить этот файл на множество небольших областей.Каждая задача будет затем читать из файла и распределять части в соответствующие выходные файлы.После этого вы можете получить окончательный процесс для объединения идентичных файлов и создания общего XML-отчета.Поскольку я предполагаю, что это в основном операция ввода-вывода (в основном это просто чтение файлов), это может дать вам гораздо большую выигрыш в производительности, чем однопоточный подход, который пытается сохранить все в памяти.
Надеюсь, это поможет!