Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.15.147.215] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Имхо, если до 2 Гб - то один большой файл, если больше - стоит подумать о совмещении двух подходов. Например, в навигационных программах карты разбиты по странам. Много мелких файлов - это кошмар, безбожно раздувающий FAT, замедляющий дефрагментацию и проверку диска, а уж о копировании (тем более на флешку) даже говорить не хочется.
|
Сообщ.
#17
,
|
|
|
Цитата Fr0sT @ Имхо, если до 2 Гб - то один большой файл а как же навигация по такому файлу? если это файл не для "поточной" обработки? |
Сообщ.
#18
,
|
|
|
_lcf_, индекс, который хранится в нём же.
|
Сообщ.
#19
,
|
|
|
Немного поделюсь своим опытом решения подобной задачи.
Много мелких файлов - зло. Когда таких файлов становится слишком много (по крайней мере, для пары десятков миллионов такой эффект наблюдался), ФС отказывается нормально работать. Например Win XP/NTFS при загрузке сообщала о неисправности ФС и предлагала поправить, но с поправкой не справлялась - процесс не мог завершиться в течение нескольких суток, после чего терпение кончалось, и диск так и оставался в "неисправном" состоянии. Кроме того, проблемы с переносом, поиском и т.п. Опять же, чтобы найти нужный файл в ФС требуется время. Один (или несколько) большой файл при статическом хранении данных лучше во всех отношения. Хуже только одно - если требуется обновление, это сразу превращается в головную боль. Правда, если обновление связано лишь с дополнением, то головной боли не возникает. Правда, и слишком большие файлы - тоже зло. Поэтому лучше искать компромисс. Я для хранения тайлов пользуюсь контейнерами двух типов. Первый тип содержит 1024 файла (квадрат 32х32 тайла), второй - 65536 (квадрат 256х256). В начале файла содержится заголовок фиксированной длины (т.к. максимальное количество файлов в контейнере известно), после него - область данных. Заголовок содержит для каждого файла смещение и длину. Контейнер имеет вполне определенное имя, а положение каждого описателя файла в заголовке известно заранее, поэтому поиск нужного происходит за O(1). При отрисовке карты у меня открыто всегда 4 файла-контейнера так, чтобы область экрана не выходила за их общую границу. Каталоги всех четырех содержатся в ОП. Т.е. для загрузки нужного файла требуется лишь позиционировать позицию чтения в нужном файле и считать фрагмент нужной длины. Никаких других операций с диском и его ФС не требуется. Два типоразмера контейнеров оказались удобными для редактирования - в маленьком (1024 файла - 10-15 Мбайт) происходят локальные изменения, а потом в пакетном режиме происходит переливание информации из маленьких контейнеров в большие (теоретически до 2 Гб, на практике не более 900 Мбайт). Размеры контейнеров выбирались так, чтобы время записи маленького было менее секунды (чтобы комфортно работать в диалоговом режиме), а размер большого не превышал 2 Гб. |