RandomAccessFile с поддержкой помимо Long?

Неправильный ответ, но вы уверены, что ваш файл действительно такой большой?

Из документации для Long.MAX_VALUE:

Константа, содержащая максимальное значение, которое может иметь тип long, 2^63-1.

Из документации для RandomAccessFile.length( ):

длина этого файла, измеренная в байтах.

Вы знаете, сколько байтов 2 ^ 63-1? Вернее, 9 223 372 036 854 775 807 байт?

9,223,372,036,854,775,807 B
9,223,372,036,854,775    KB
9,223,372,036,854        MB
9,223,372,036            GB
9,223,372                TB
9,223                    PB
9                        EB

Если я правильно подсчитал, вам потребуется постоянная скорость записи около 272 ГБ/с в течение 1 года.

Хотя это отличный вопрос, на который я хотел бы увидеть ответ, я очень сомневаюсь, что у вас есть один файл размером 9EB, если ОС вообще будет поддерживать это.

изменить

Вот некоторые ограничения файловой системы и, к моему большому удивлению, NTFS будет фактически поддерживать отдельные файлы до 16EiB, однако это только один из немногих в списке, которые его поддерживают.

Если вам АБСОЛЮТНО необходимо получить доступ к файлу размером более 9EiB, похоже, вам может понадобиться создать собственную версию RandomAccessFile, используя BigInteger, где другой использует long. Это может дать вам до (2 ^ 32) ^ Integer.MAX_VALUE байт.

Я полагаю, что ваш вопрос связан с этим требованием: «Есть ли что-то еще, что я могу использовать, что поддерживает адресное пространство за его пределами». Другими словами, вы хотите получить доступ к памяти по адресу, и ваш адрес может быть большим.

Конечно, вы не должны выделять файл размером 2^128 * 6 байт, даже если бы это было возможно в наши дни, это было бы слишком дорого. Типичный подход здесь состоит в том, чтобы разделить хранилище на более мелкие части и адресовать их соответствующим образом. Например

write(partition, address, node);
node = read(partition, address);

Как вы сказали, вы должны хранить адреса IPv6. Для хранения IPv6 и быстрого поиска по нему достаточно иметь таблицу с 8 столбцами и индексами для каждой части адреса ipv6. Или вы можете хранить информацию в древовидной иерархии, например:

• 0000
  • 0000
    • 0000
      • etc
  • 0001
    • 0000
      • etc

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

ОБНОВИТЬ

Хочу отметить, что на самом деле в Java есть приватный API (Oracle JDK, а не OpenJDK), который может дать вам возможность обрабатывать файлы больше 2 Гб, но он приватный, вообще не является частью публичного API, так что я бы не стал описывать его здесь, без просьб. Вы можете найти его непосредственно в sun.nio.ch.FileChannelImpl (приватные методы map0, unmap0).

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

Итак, поскольку основная проблема заключается в аппаратных ограничениях одной машины, решением будет использование распределенной вычислительной среды, которая позволит вам масштабироваться настолько, насколько это необходимо. Я предлагаю использовать https://ignite.apache.org/, так как он невероятно гибкий и имеет довольно достойную поддержку. здесь при переполнении стека.

Если посмотреть на это с другой точки зрения, вы хотите хранить IP-адреса IPv6. На теоретическом уровне вам понадобится 2 ^ 64 адреса. На практическом уровне, даже если вы попытаетесь проиндексировать каждый IP-адрес сегодня, вы не превысите 2 ^ 32, поскольку это количество адресов IPv4, а мы просто превышаем этот предел.

Да, это 18.4467441 эксабайт, что очень много. Вы не можете хранить это в памяти, так как нет ни компьютера, ни даже кластера с такой памятью (ОЗУ).

Конечно, вы можете писать в файлы. Но это обязательно должно быть несколько файлов. Я не думаю, что возможно иметь 1 такой большой файл. И если бы это было возможно, поиски заняли бы часы или дни. Итак, есть 2 подхода:

1. Разделить на несколько файлов меньшего размера

2. Используйте «потоки» — читайте немного, обрабатывайте, записывайте и читайте дальше.

Возможно, это глупое наблюдение, но думали ли вы о сериализации? ваша структура данных? В Интернете есть много примеров, я нашел этот простой пример, который вы можете настроить для своего дерева , затем вы можете выполнить преобразование для сохранения данных.