Каков наилучший способ чтения большого файла (> 2 ГБ) (текстовый файл содержит данные rnet) и случайного доступа к данным по различным параметрам?

Question

У меня есть текстовый файл, который выглядит следующим образом:

0.001 ETH Rx 1 1 0 B45678810000000000000000AF0000 555
0.002 ETH Rx 1 1 0 B45678810000000000000000AF 23
0.003 ETH Rx 1 1 0 B45678810000000000000000AF156500
0.004 ETH Rx 1 1 0 B45678810000000000000000AF00000000635254

Мне нужен способ прочитать этот файл и сформировать структуру и отправить ее клиентскому приложению.

В настоящее время я могу сделать это с помощью циклической очереди Boost.

Здесь необходимо получить доступ к разным данным в разное время.

Пример: если я хочу чтобы получить доступ к данным на 0.03se c, в то время как я в данный момент нахожусь на 100se c, как я могу сделать это наилучшим образом вместо отслеживания указателя файла или сохранения всего файл в память, которая вызывает узкое место производительности? (Учитывая, что у меня есть файл размером 2 ГБ с данными вышеуказанного типа)

Answer 1

Как правило, лучший способ обработки больших файлов зависит от архитектуры платформы (x86 / x64) и ОС (Windows / Linux et c.)

. Поскольку вы упомянули надстройку, рассматривали ли вы возможность использования увеличить карту памяти? Файл с увеличенной памятью

Answer 2

Вот решение, которое я нашел:

1. Использовал кольцевые буферы (Boost Lock Free Buffers) для анализа файла и для сохранения структурированного формата строки
2. Используется отдельными потоками:
   • Один будет непрерывно анализировать файл и pu sh, чтобы заблокировать свободную очередь
   • Один будет непрерывно читать из буфера, обрабатывать строку, формировать структуру и pu sh в другую очередь
   • Всякий раз, когда пользователю нужны случайные данные, основанные на времени, я перемещаю указатель файла на определенную строку и считываю только определенную строку.
3. Оба потока имеют механизмы ожидания мьютекса для прекратите синтаксический анализ, как только предопределенный лимит буфера достигнет
4. . Пользователь получит данные в любое время, и нет необходимости сохранять полное содержимое файла. Как и когда кадр будет прочитан, я буду удалять кадр из очереди. Так что размер файла не имеет значения. Параллельные потоки, которые заполняют буферы, позволяют не тратить время на чтение файла каждый раз.
5. Если я хочу перейти к другой строке, переместить указатель файла, стереть существующие данные, снова запустить потоки.

Примечание: Теперь проблема только в том, чтобы переместить указатель файла на определенную строку. Мне нужно анализировать построчно, пока я не достигну точки.

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

Я ценю, если кто-нибудь даст решение для вышеупомянутой новой проблемы!

Answer 3

Все зависит от

• a. как часто доступ к данным

• b. какой шаблон доступа к данным

  1. Разделение файла Если вам нужно время от времени получать доступ к данным, тогда этот дизайн журнала 2 ГБ подойдет, если не регистратор может быть настроен для создания журнала с периодом c интервал / последний, а logi c может разбивать файлы размером 2 ГБ на нужные файлы меньшего размера. Таким образом, получение файла журнала в ранжированном виде, а затем чтение данных журнала и последующая сортировка необходимых строк будет проще, так как здесь будут уменьшены байты чтения файла.

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

  3. База данных Если шаблон поиска не упорядочен / динамически растет при использовании, тогда данные база будет работать. Опять же, здесь это не даст более быстрого ответа, как небольшой кеш.

  4. Сочетание базы данных с идеальной организацией таблиц для поддержки типа запроса + меньший уровень кеша даст оптимальный результат.