На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! В разделе обсуждаются следующие темы:
1) Процесс разработки программного обеспечения.
2) Определение требований к программному обеспечению.
3) Составные части и процесс проектирования (см. Шаблоны проектирования).
4) Документирование программного продукта(проекта).
5) Руководство разработкой программного обеспечения.
6) Проектирование пользовательского интерфейса.
7) Контроль версий проекта (см. Управление версиями в Subversion, Стратегии использования svn).
Модераторы: ElcnU
Страницы: (2) 1 [2]  все  ( Перейти к последнему сообщению )  
> 1 млн. маленьких файлов VS 1 большой файл
    Имхо, если до 2 Гб - то один большой файл, если больше - стоит подумать о совмещении двух подходов. Например, в навигационных программах карты разбиты по странам. Много мелких файлов - это кошмар, безбожно раздувающий FAT, замедляющий дефрагментацию и проверку диска, а уж о копировании (тем более на флешку) даже говорить не хочется.
      Цитата Fr0sT @
      Имхо, если до 2 Гб - то один большой файл

      а как же навигация по такому файлу? если это файл не для "поточной" обработки?
        _lcf_, индекс, который хранится в нём же.
          Немного поделюсь своим опытом решения подобной задачи.

          Много мелких файлов - зло. Когда таких файлов становится слишком много (по крайней мере, для пары десятков миллионов такой эффект наблюдался), ФС отказывается нормально работать. Например Win XP/NTFS при загрузке сообщала о неисправности ФС и предлагала поправить, но с поправкой не справлялась - процесс не мог завершиться в течение нескольких суток, после чего терпение кончалось, и диск так и оставался в "неисправном" состоянии.
          Кроме того, проблемы с переносом, поиском и т.п.
          Опять же, чтобы найти нужный файл в ФС требуется время.
          Один (или несколько) большой файл при статическом хранении данных лучше во всех отношения. Хуже только одно - если требуется обновление, это сразу превращается в головную боль. Правда, если обновление связано лишь с дополнением, то головной боли не возникает.

          Правда, и слишком большие файлы - тоже зло. Поэтому лучше искать компромисс.

          Я для хранения тайлов пользуюсь контейнерами двух типов.
          Первый тип содержит 1024 файла (квадрат 32х32 тайла), второй - 65536 (квадрат 256х256).
          В начале файла содержится заголовок фиксированной длины (т.к. максимальное количество файлов в контейнере известно), после него - область данных.
          Заголовок содержит для каждого файла смещение и длину.
          Контейнер имеет вполне определенное имя, а положение каждого описателя файла в заголовке известно заранее, поэтому поиск нужного происходит за O(1).

          При отрисовке карты у меня открыто всегда 4 файла-контейнера так, чтобы область экрана не выходила за их общую границу. Каталоги всех четырех содержатся в ОП. Т.е. для загрузки нужного файла требуется лишь позиционировать позицию чтения в нужном файле и считать фрагмент нужной длины. Никаких других операций с диском и его ФС не требуется.

          Два типоразмера контейнеров оказались удобными для редактирования - в маленьком (1024 файла - 10-15 Мбайт) происходят локальные изменения, а потом в пакетном режиме происходит переливание информации из маленьких контейнеров в большие (теоретически до 2 Гб, на практике не более 900 Мбайт).
          Размеры контейнеров выбирались так, чтобы время записи маленького было менее секунды (чтобы комфортно работать в диалоговом режиме), а размер большого не превышал 2 Гб.
          0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
          0 пользователей:


          Рейтинг@Mail.ru
          [ Script execution time: 0,0211 ]   [ 15 queries used ]   [ Generated: 28.03.24, 09:47 GMT ]