Копирование части кэша

[svp]

Чевой-то не видел.

Речь шла. в частности, об исходниках конвертера. Они лежат в этой теме http://sasgis.ru/forum/viewtopic.php?f=2&t=23

[Cowa]

А, видел. Сорри. Но это к вопросу конвертации. Меня больше устраивает кеш Планеты. Кстати, очень грамотно распределен по папкам. Винда, вообще не любит много файлов в одной папке.

[svp]

Меня больше устраивает кеш Планеты

Меня тоже, в общем, устраивает. Поэтому я и написал конвертер.
Однако у кеша Планеты есть и минусы: По имени любого файла из кеша нельзя определить его координаты и масштаб не анализируя полный путь к нему. Этот минус легко устранить, введя некоторую избыточность в именовании тайлов. Речь идёт о добавлении к имени тайла (например, "y150.jpg") полной информации о его координатах (y150_x130_z15).
Парсить такие имена не многим сложнее, однако окажется доступной возможность быстрого системного поиска файлов с условиями и дальнейшего разбрасывания найденных файлов по каталогам нового хранилища.

[bk99]

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

Отлично! Молодец! Давно ждал чего-то подобного.
И, раз уж, зашёл разговор, предлагаю (набравшись наглости!) уважаемому автору (и примкнувшим к нему добрым самаритянам - я, к сожалению, "языками не владею") подумать над более универсальным синхронизатором кэшей.
Пример: есть два компа (не связанных друг с другом) с Планетой. Требуется залить, скажем, на флешку, с одного компа только ту часть кэша, которой нет на втором компе. Ну и, соответственно, слить с флешки эту часть на второй комп (т.е. объединить с кэшем второго компа). То, что предлагает выше уважаемый автор будет лишь частным случаем такого универсального синхронизатора.

[Cowa]

bk99
В принципе, реально это сделать. Ничего сложного. Но для этого нужно будет (при наличии функции сравнения) запустить утилиту на втором компе, найти все файлы в папке cache, далее выгрузить этот список в файл. Потом перейти на первый комп, загрузить файл со списком тайлов второго компа. Запустить функцию сравнения и затем скопировать несовпадающие файлы в другую папку. Скопировать папку на флешку и, перетащив на второй комп переместить в папку cache. По-моему геморой. Очень сложно для понимания.

Эта задачка с текущей версией утилиты делается так: один раз весь кеш одного компа копируется в кеш второго компа, а затем уже изменения в кешах ( хоть первого компа, хоть второго), зная дату их создания, копируются в отдельную папку, и потом переносятся на другой комп. Это таже синхронизация.
Или я что не понял. Но я делаю именно так.

P.S. А вот функции удаления мне уже не хватает в утилите. Бывает скачаешь из интернета случайно не ту область... Зачем захламлять и без того огромный cache.

[svp]

Не, ребят.. когда размер кеша приближается к 5 гигам, как у меня. Вопрос о том, чтобы копировать лишний раз куда-то каталог с кешем отпадает ввиду того, что копирование будет продолжаться несколько суток. Проблема не в объёме, а в количестве файлов и времени доступа к этим файлам.
По-любому надо городить какую-то базу-беркли.
Кроме того. Чем больше кеш, тем сложнее становится делиться его фрагментами с другими планетоводами, а это не есть хорошо. Ситуацию опять же поправит быстрый доступ к тайлам. То есть опять же база беркли.
Ещё имеет смысл хранить основной кеш до какого-то (полагаю до 10-15) уровня в одном файле (БД Беркли), а детальные кеши городов в отдельных файлах. Это даст возможность легко меняться отдельными городами.
Сейчас я задвинул KML и как раз разбираюсь с БД Беркли. Разберусь -- набросаю компонентик для хранения кешей в берклиобразной структуре, а потом буду убеждать нашего азю добавить это дело в проект.

Насчет копирования части кеша. Нужно уметь:

1. Быстро слить два кеша.
2. Отделить тайлы, соответствующие фильтру в другой кеш.

Фильтры:

1. По дате.
2. По размеру файла.
3. По принадлежности к многоугольнику, заданному цепочкой координат.
4. По уровню (zoom).
5. По наличию тайла в другом кеше.
6. По комбинации пунктов 1-5.

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

Также можно реализовать возможность создания т.н. индексного кеша. Об этом

Очень сложно для понимания

Как это лучше понимать:
Индексный кеш -- это такой же обычный кеш, только в нём содержатся пустые тайлы. Вернее информация об их наличии, размере и дате/времени создания.
Такой индексный кеш будет занимать на порядки меньше места, а также будет эффективно сжиматься архиваторами. Нужен он для того, чтобы на основе него с помощью фильтра №5 (см. выше) формировать дифференциальный кеш для обмена, недостающими кусками закачек, например, через интернет, когда нет никакого желания бестолку копировать ненужную информацию.

Чуть не забыл. Чтобы поддерживать возможность хранения детальных кешей в разных файлах, нужно для каждого кеша указывать (при необходимости) набор фильтров, которому должны удовлетворять его тайлы.
Если какая-то программа хочет поддерживать распределённый кеш то:
1. Она должна зарегистрировать в себе все поддерживаемые фрагменты кешей:
2. При поиске тайла в совокупном кеше нужно перебирать кеши в порядке регистрации и проверять совпадение свойств тайла с фильтрами кеша. При совпадении ищем в выбранном кеше нужный тайл. Не находим -- продолжаем обход зарегистрированных кешей.
3. При добавлении тайла в совокупный кеш нужно также как и при выборке обходить кеши по очереди и добавить тайл только в подходящий кеш.
4. Для хранения фрагментов кеша на FTP, локально-сетевом сервере или на сервере в инете, можно регулярно выкладывать индексный кеш этого удалённого хранилища для чтения. Клиенты, зарегистрировавшие у себя удалённое хранилище, будут регулярно забирать индексный кеш хранилища и по нему определять наличие нужного тайла.

вот.. всё достаточно просто, господа=). По крайней мере есть перспективы развития.

P.S.
Про базы Беркли можно почитать здесь
http://www.inode.ru/articles/database/2006-02-12/296

[bk99]

bk99
В принципе, реально это сделать. Ничего сложного. Но для этого нужно будет (при наличии функции сравнения) запустить утилиту на втором компе, найти все файлы в папке cache, далее выгрузить этот список в файл. Потом перейти на первый комп, загрузить файл со списком тайлов второго компа. Запустить функцию сравнения и затем скопировать несовпадающие файлы в другую папку. Скопировать папку на флешку и, перетащив на второй комп переместить в папку cache. По-моему геморой. Очень сложно для понимания.
Эта задачка с текущей версией утилиты делается так: один раз весь кеш одного компа копируется в кеш второго компа, а затем уже изменения в кешах ( хоть первого компа, хоть второго), зная дату их создания, копируются в отдельную папку, и потом переносятся на другой комп. Это таже синхронизация.
Или я что не понял. Но я делаю именно так.

Согласен, текущая версия позволяет это сделать. Ни в коей мере не хочу принижать достоинства этой утилиты (поскольку сам не смогу написать ничего подобного - увы, чукча не писатель, чукча пользователь!). Я-то как раз предполагал именно то, что ты написал выше (см. цитату). В идеале я вижу так: один комп (назовём его "базовым") собирает (объединяет) кэш с других компов (назовём их, скажем, "вторичными"). Итак, запускаю прогу на базовом компе, создаётся индексный файл - файл, содержащий список всех имеющихся на нём тайлов. Перетаскиваю этот индексный файл вместе с утилитой на флешку и иду на один из вторичных компов. Запускаю на нём утилиту. Она копирует с него тайлы, которые отсутствуют в индексном файле. Иду на базовый комп и, опять запустив утилиту, сливаю эти новые тайлы в кэш базового. Преимущества - можно собирать кэш с разных вторичных компов и не заморачиваться с запоминанием даты создания. Для пользователя всё должно быть просто, одной кнопкой, что называется "для солдат". Конечно, потом в эту утилиту можно внести всякие красивости:

Фильтры:
1. По дате.
2. По размеру файла.
3. По принадлежности к многоугольнику, заданному цепочкой координат.
4. По уровню (zoom).
5. По наличию тайла в другом кеше.
6. По комбинации пунктов 1-5.

Но, ещё раз повторюсь, Cowa, к тебе никаких претензий! Ты молодец, утилитка полезная. А все мои рассуждения - это так, из разряда пожеланий. Аппетит, как известно, приходит во время еды!
Спасибо!

[Cowa]

svp
М-да, серьезный подход к вопросу . Попробую высказать свое мнение по этому вопросу. Но прежде задам вопрос: когда пытаются что-то глобально поменять, то должна быть веская причина. Что именно не устраивает в текущей структуре кеша: неудобная структура для использования кеша в других программах, создание своей программы с другим типом хранения тайлов, медленная работа приложения по считыванию тайла из кеша, огромный объем, и пр.
Итак.
1. Лишний раз копировать кеш не нужно. А кеш объемом в 5 гигов архивируется раром с минимальным сжатием, дабы получить один файл или разбить на несколько, если система не ntfs. потом перенести в нужное место и распаковать. Займет времени пару - тройку часов.
2. Хранить кеш в одном файле или нескольких - на мой взгляд не лучшая идея. Смысл? Не думаю, что при этом уменьшится время обращения к тайлам, т.к. будут добавлены дополнительные механизмы по обработке данных в новом кеше, индексированию его и т.п. С базами данных работали? БД хороша до определенного объема данных в ней. Потом начинаются проблемы. Да и в случае ошибки механизма, перебоя напряжения в сети и пр. база может грохнуться, причем вся а не отдельный испорченный тайл. А база в случае с тайлами будет ох как не малой.
3.

Индексный кеш -- это такой же обычный кеш, только в нём содержатся пустые тайлы. Вернее информация об их наличии, размере и дате/времени создания.Такой индексный кеш будет занимать на порядки меньше места,

Кто считал? В идеале нужно иметь информацию по всем тайлам, всех уровней всего земного шара. Даже если на одну запись 1 байт(что мало), то размер индексного файла для тайлов с уровня 1 по 23 будет около 23500 Gb. Кто похвастается таким винтом у себя на компе? Если оперировать частью кеша, то в принципе, все реально, но все равно (если не вводить ограничения по использванию области карты для кеша) рано или поздно он вырастит до гигантских размеров.
Вот, собственно, и все. Повторюсь - это мое мнение. Возможно я в чем-то ошибаюсь - поправьте.
Вся проблема в том, что в кеше может быть СЛИШКОМ много файлов. И оперировать таким объемом - очень не простая задачка. И приходится искать середину между простотой структуры кеша,( а значит скоростью обращения к тайлам) и удобству и универсальности делать из него выборки тайлов для каких либо задач ( скорость падает, дополнительные проблемы по сохранности всего кеша).

bk99

Для пользователя всё должно быть просто, одной кнопкой

Одной кнопкой не получится. Нужно будет понимать логику. Ок, попробую добавить. Правильно говорят, программу как и ремонт нельзя закончить, можно только приостановить.

[svp]

Возможно я в чем-то ошибаюсь - поправьте.

Сейчас буду поправлять=)

вопрос: когда пытаются что-то глобально поменять, то должна быть веская причина. Что именно не устраивает в текущей структуре кеша: неудобная структура для использования кеша в других программах, создание своей программы с другим типом хранения тайлов, медленная работа приложения по считыванию тайла из кеша, огромный объем, и пр.

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

1. Лишний раз копировать кеш не нужно.

Весь не нужно. А какие-то его больше фрагменты хотелось бы.

2. Хранить кеш в одном файле или нескольких - на мой взгляд не лучшая идея.

Напротив. Это отличная идея. Посмотрите, например, Google Earth.

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

Ошибаетесь. Вот, как раз, благодаря индексации скорость доступа только ускорится.

С базами данных работали? БД хороша до определенного объема данных в ней. Потом начинаются проблемы. Да и в случае ошибки механизма, перебоя напряжения в сети и пр. база может грохнуться, причем вся а не отдельный испорченный тайл. А база в случае с тайлами будет ох как не малой.

С БД работал и работаю постоянно. А Вы к ним, я вижу, относитесь несколько предвзято. К тому же речь идёт не об обычной реляционной базе данных, а о базе Berkeley. Эти базы специально расчитаны на огромные объёмы данных в ней (до сотен терабайт) и на быстрый доступ к записи по ключу. Причем налажены простые, но действенные механизмы транзакций, восстановления после сбоев и т.д. Почитайте ту статью, ссылку на которую я положил в прошлом посте. Так что грохнется не вся база, а именно тайлы, добавленные во время последней транзакции.

В идеале нужно иметь информацию по всем тайлам, всех уровней всего земного шара. Даже если на одну запись 1 байт(что мало), то размер индексного файла для тайлов с уровня 1 по 23 будет около 23500 Gb. Кто похвастается таким винтом у себя на компе?

Эти расчеты не имеют никакого отношения к действительности. Эта ваша "идеальная" ситуация практически не достижима. К тому же она никому и не нужна. Я уже говорил, что в 19 масштабе доступны только достаточно крупные города и стратегические объекты с окрестностями. Столицы и действительно интересные объекты доступны в 20-21 уровне. Но это очень-очень-очень маленький процент всей площади Земли. Существуют поистине огромные участки океанов, пустынь, степей, тайги, которые просто никому не интересны. Никто не будет тратить время и деньги на их съёмку и хранение. Технически сложно сканировать приполярные районы: туда спутники не долетают. Почти весь земной шар доступен (без океанов) в 10 уровне. Этот слой занимает около гигабайта и в нём нет поверхности океанов. Предыдущие слои весят в четыре раза меньше. Следующий (11) в идеале будет весить 4 гига. Но уже в нём доступна не вся площадь поверхности суши. Короче нет никакого смысла хранить в индексе этот "идеальный" случай. Его просто не бывает и не будет никогда (имеются виду ближайшие сто лет=).

Можно хранить тайлы в общем кеше вплоть до 14-15 уровня, но детальные (18-21) кеши городов имеет смысл выносить в отдельные структуры. По кешу на детальную область близ крупного города.
Как конкретно это хранить, в одном ли файле, или в дереве каталогов -- это отдельный вопрос. Но разделять детальные кеши географически неизбежно придётся. Всем хочется иметь в кеше Москву, Питер и Париж. Но люди, там не живущие, будут пользоваться ими гораздо реже чем своим городом.

Вся проблема в том, что в кеше может быть СЛИШКОМ много файлов. И оперировать таким объемом - очень не простая задачка.

Объёмом оперировать ка краз не так уж и сложно. Проблема, повторюсь, в файловой системе, которая копирует один файл в 5 гигов ГОРАЗДО быстрее чем 5 гигов файлов по 10-30 килобайт.
Опять же много проблем решит разделение кеша на отдельные для каждого детального участка. Не надо перебирать и фильтровать огромное количество файлов. Достаточно скопировать целиком один кеш. и всё.

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

Файловая система как раз не обеспечивает достаточной скорости доступа. Berkeley DB обеспечила бы гораздо большую скорость. Причем внутренняя техническая структура была бы также проще.
В общем хранение тайлов в отдельных файлах без индекса -- это медленнее в
любом случае.

Одной кнопкой не получится. Нужно будет понимать логику.

Да. Одной кнопкой никак. Двумя=). Можно педставить то, о чем идёт речь, как заявку.
То есть сформировать список тайлов, которые: ... . Нпример, которых не хватает у меня дома, а на работе есть. Или которые есть у меня дома.
Ну и простые логические операции: вычесть один список из другого, доьавить один список к другому, пересечь два списка. В резуьтате всегда будет получаться третий список так или иначе нужный нам и с понятным назначением. Можно понимать список как заявку не тайлы=).

[Cowa]

Небольшие изменения в CacheCopy. Забираем - http://slil.ru/26168510
По просьбам трудящихся.
Добавлена кнопка удаления файлов по списку. Есть галочка - удаляются либо в корзину, либо с "концами". Во втором случае почти мгновенно. Пустые папки, к сожалению, не удаляются (пока ).
Добавлена кнопка выгрузки списка в файл. На закладке Compare его можно загрузить на др.компе и сравнить с текущим списком. Короче в списке остаются файлы, которых нет в загруженном списке. Сумбурно объяснил - попробуете - станет понятно. Единственно медленно работает. Мучился с оптимизацией - в лучшем случае мои тестовые 25000 файлов сравнивает около 80 сек. Ладно потом придумаю что-нибудь. А так в принципе, действительно иногда бывает полезно.
Ну и так, добавлены некоторые мелочи.
НА днях попробую сделать фильтры по уровню.