Вопросы по исходному коду

[kellwin]

А по-подробнее можно? Каким образом там уменьшится количество тайлов?

По-подробнее: при моих размерах кеша (десятки миллионов файлов) уменьшение их количества прибл. в 100 раз
сняло бы большинство проблем с копированием, бэкапом и т.д.
Этого можно добиться упаковкой всех файлов каждого терминального подкаталога в 1 - если каталог полностью заполнен, их там 1000, так что среднего уменьшения в 100 раз добиться вполне возможно.
Упаковку я бы хотел делать в специальный формат, в котором можно было бы легко определить, есть тайл или нет.
В общих чертах, это заголовок, массив из 1024 смещений на данные тайлов и сами данные (атрибуты+файл).
При этом я бы хотел разделить закачку тайлов и создание кеша, поскольку дергается он часто, и если вылетит ошибка файловой системы, то перезакачивать придется дост. много.
Поэтому предполагаемая схема работы такая:
Во время закачки:
на чтение тайла - сначала смотрим, есть ли файл в каталоге, затем есть ли кеш в каталоге и есть ли в нем тайл;
на запись - так же, как сейчас, ничего не меняется;
на удаление тайла - тут придется дергать кеш - чистим смещение в массиве и выставляем dirty-флаг в заголовке кеша.

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

А так кеш получается совместимым с текущим (нет файла кеша, и не надо), и все, что мне надо от САС, - определиться,
куда вставить чтение тайла из кеша. Ну и для оптимизации еще неплохо кешировать последний открытый кеш, и закрывать его при выходе из программы.

Коммит с Беркли попробую поизучать, спасибо

[vdemidov]

Я бы посоветовал не привязываться к сасовской структуре кэша, а делать что-то в духе qrts именования тайлов с упаковкой тайлов в контейнеры по 256 штук. Это позволит гораздо эффективнее кэшировать запросы к такому кэшу
И еще не забывайте о необходимости тредсейфовости тайлохранилища.

[zed]

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

Предложений по новым типам кэшей поступало уже достаточно много - поищите в Багтрекере, может какой-то вариант вас заинтересует. На вскидку:
- 0001376: Новый тип кэша в формате MBtiles (на основе SQLite3)
- 0001291: Поддержка кэша SAS4WinCE (только для чтения)
- 0001290: Поддержка вторичного read-only кэша (например, в формате SAS4WinCE)
- 0001113: Хранилище на основе СУБД
- 0001053: Работа САС.Планеты со сторонними кэшами (МЯК и другими) напрямую
- 0000653: Отображать тайлы из архива

[kellwin]

Я бы посоветовал не привязываться к сасовской структуре кэша, а делать что-то в духе qrts именования тайлов с упаковкой тайлов в контейнеры по 256 штук. Это позволит гораздо эффективнее кэшировать запросы к такому кэшу
И еще не забывайте о необходимости тредсейфовости тайлохранилища.

Я бы хотел как раз привязаться к сасовской структуре, поскольку в идеале она позволит упаковать 1024 файла в 1 контейнер, что лучше, чем 256 К тому же мне было бы проще доделать существующий юнит, чем писать заново.
Тредсейфовость вроде как обеспечивается файловой системой - через блокировку файлов.

[kellwin]

Понятно. Тоже были похожие мысли, но потом пришёл к выводу, что это получится не надёжно (если САС упадёт в критический момент, то полетит весь файл-контейнер) и неприменимо для 2-х и более одновременно-работающих САСах с одним кэшем.

Поэтому я и хочу разделить закачку тайлов и создание/обновление кеша на разные процедуры. А уже при создании/обновлении гарантировать надежность контейнера достаточно просто.
Проблем для 2-х САСов с одним кешем я тоже не вижу, поскольку в момент закачки/просмотра кеш открывается только на чтение, и ненадолго (заголовок+массив смещений кешируется в память). А операцию упаковки можно прогнать и отдельно, когда несколько одновременно работающих САСов не нужны.

[zed]

поскольку в идеале она позволит упаковать 1024 файла в 1 контейнер, что лучше, чем 256

Это не в идеале, а только на 20-м зуме по-моему (или даже только на 24-м). Чем меньше зум, тем меньше наполненность каталогов и тем больше ненужных подкаталогов с парой папок/файлов.

[vdemidov]

Тоес

Я бы хотел как раз привязаться к сасовской структуре, поскольку в идеале она позволит упаковать 1024 файла в 1 контейнер, что лучше, чем 256 К тому же мне было бы проще доделать существующий юнит, чем писать заново.

Учитывая общее количество кода, которое нужно будет написать это экономия на спичках. Общего кода там будет ровно 1 строчка
1024 в одном контейнере это в 4 раза больше потерянных данных в случае любых глюков по сравнению с 256, но это не принципиально. Принципиально хранение тайлов большими квадратами, а не столбцами. Просто для заполнения экрана 1920х1280 нужно в твоем случае обращаться к 9 контейнерам, а в случае с qrts именованием максимум к 4 контейнерам.

Тредсейфовость вроде как обеспечивается файловой системой - через блокировку файлов.

Мечты-мечты. Ну или тормоза-тормоза

[vdemidov]

поскольку в идеале она позволит упаковать 1024 файла в 1 контейнер, что лучше, чем 256

Это не в идеале, а только на 20-м зуме по-моему (или даже только на 24-м). Чем меньше зум, тем меньше наполненность каталогов и тем больше ненужных подкаталогов с парой папок/файлов.

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

[zed]

А операцию упаковки можно прогнать и отдельно, когда несколько одновременно работающих САСов не нужны.

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

[vdemidov]

Понятно. Тоже были похожие мысли, но потом пришёл к выводу, что это получится не надёжно (если САС упадёт в критический момент, то полетит весь файл-контейнер) и неприменимо для 2-х и более одновременно-работающих САСах с одним кэшем.

Поэтому я и хочу разделить закачку тайлов и создание/обновление кеша на разные процедуры. А уже при создании/обновлении гарантировать надежность контейнера достаточно просто.
Проблем для 2-х САСов с одним кешем я тоже не вижу, поскольку в момент закачки/просмотра кеш открывается только на чтение, и ненадолго (заголовок+массив смещений кешируется в память). А операцию упаковки можно прогнать и отдельно, когда несколько одновременно работающих САСов не нужны.

Ну тоесть у вас очередная вариация на тему ридонли кэша в довесок к рабочему все с той же кучей вопросов по реализации что и здесь:
- 0001290: Поддержка вторичного read-only кэша (например, в формате SAS4WinCE)