Редактирование больших файлов данных - PullRequest
2 голосов
/ 12 января 2010

Я собираюсь начать проект, в котором я могу предвидеть, что будут большие файлы (в основном плоские текстовые файлы, но могут быть CSV, фиксированной ширины, XML и т. Д.), Которые необходимо редактировать. Мне нужно разработать части для этого редактирования в приложении.

Пытаясь найти хороший способ обработки больших объемов данных (возможно, в диапазоне ГБ) без необходимости загружать все это, я обнаружил, что Audacity способен обрабатывать большие файлы довольно хорошо. Audacity - это открытый исходный код, поэтому я подумал, что он станет для меня отличным инструментом обучения в таких условиях. Тем не менее, я начал думать по кругу, просматривая код, и теперь я полностью сбит с толку.

Я надеюсь получить два результата из этого вопроса:

  1. Хороший способ обработать это редактирование без загрузки всего файла. Я думал о загрузке данных по мере их редактирования, кэширования по требованию.

  2. Объяснение того, как это делает Audacity.

Я использую C # и .NET, но ответы не нужно привязывать к этой среде.

Ответы [ 2 ]

2 голосов
/ 12 января 2010

Несколько трюков могут сделать редактирование проще и быстрее.

  1. УКАЗАТЬ его для более быстрого доступа. Пока пользователь ничего не делает, просмотрите файл и создайте индекс, чтобы вы могли быстро найти определенное место в файле (см. Ниже).
  2. Сохранять только те изменения, которые вносит пользователь. Не пытайтесь применить их непосредственно к файлу, пока пользователь не сохранит данные.
  3. Установить ограничение на объем чтения в память, когда пользователь переходит к точке. Сначала прочитайте один или два экрана данных, чтобы вы могли их отобразить, а затем, если пользователь не сразу перейдет на новое место, прочитайте немного раньше и немного позже текущего места.

Индексация:

Когда пользователь хочет перейти на строку X или метку времени T , вы не хотите просматривать весь файл, считая разрывы строк и символов. Просмотрите данные и создайте запись. Скажем, каждые 50 строк записывают смещение байта, количество символов и номер строки. Эти данные могут храниться в хеш-таблице, дереве или просто упорядоченном списке. Затем, когда пользователь переходит в файл, вы можете найти ближайшее место индекса и читать оттуда, пока не найдете запрошенную точку. Этот метод особенно полезен при работе с Unicode, где количество байтов на символ может варьироваться. Если файлы настолько велики, полный индекс не помещается в памяти, вы можете ограничить индексные точки и разместить их более широко или сохранить индекс во временном файле.

Редактирование и изменение больших файлов:

В соответствии с предложением Харви - только сохраняет изменения в памяти (в виде различий), а затем применяет их к файлу при сохранении путем потоковой передачи от ввода к выводу. Дерево или упорядоченный список могут быть полезны, так что вы можете быстро найти следующее место, где вам нужно внести изменения при записи от ввода к выводу.

Если изменения слишком велики, чтобы поместиться в памяти, вы можете отследить их в отдельном временном файле (возможно, в той же папке, что и оригинал). Вы можете просто продолжать писать непрерывный список изменений, с новыми, добавленными к этому файлу изменений. При сохранении вы прочитаете список изменений и создадите окончательный список изменений, которые нужно применить, прежде чем удалять временный файл. Из соображений производительности может быть полезно избежать перезаписи файла журнала изменений; вместо этого просто добавьте его в конец и удалите лишние или отменяющие изменения при выполнении сохранения.

Интересный факт: те же структуры, которые вы используете для журнала изменений, могут использоваться для предоставления информации отмены / повтора.

2 голосов
/ 12 января 2010

Звуковые файлы - это в основном поток данных, верно? Таким образом, вам на самом деле не нужно иметь дело со всем файлом сразу. Пользователи Audacity могут работать только с небольшим фрагментом этого большого файла в любой момент.

Гипотетически, если вы добавляете 1-секундный фрагмент звука к большому звуковому файлу, вам действительно нужно иметь дело со всем файлом только тогда, когда вам нужно сохранить, после чего вы склеиваете 3 части: до, 1 секунда фрагмент, а после. Таким образом, единственное, что должно быть в памяти, - это 1-й фрагмент, и, возможно, небольшая часть звука до и после фрагмента.

Поэтому, когда вы сохраняете, вы читаете, скажем, 64 мегабайта файла за раз (если вы действительно агрессивны), и передаете его во временный файл, пока не дойдете до точки вставки. Затем вы выводите 1-секундный фрагмент, передаете оставшуюся часть исходного файла, закрываете временный файл записи, удаляете исходный файл и переименовываете новый файл в исходное имя файла.

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

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