Библиотека модулей для работы с гео-тайлами [Python]

[svp]

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

• Класс tileid для хранения и основных операций с индексом тайла (координаты+зумм).
  Компактный бинарный формат пригоден для использования в качестве индекса БД. Технически индекс представляет собой неизменяемый объект (в терминологии Питона) потомок от типа long.
  Реализует итератор по цепочке предков от корня. Инициализируется из различных видов записи: координатной (x, y, z), пирамидальной ("qrts" или [0, 1, 2, 3]), пирамидально-бинарной.
• Класс tileset для хранения маски заполнения тайлового поля.
  Изначально предназначался для быстрой проверки наличия тайла в хранилище, но на данный момент функционал класса позволяет делать очень интересные вещи.
  Экземпляр класса предназначен для хранения информации о заполнении одного тайлового слоя в одном масштабе, например, sat\z19. Информация о тайлах эффективно хранится в дереве так, что, например, полностью заполненный или полностью пустой слой занимает в дереве всего один узел. Кроме того, в дереве можно хранить не только двоичные состояния тайлов (есть/нет), но и более широкий набор информации, например, неизвестно/есть/нет/загрузился_с_ошибкой и т.д.
  На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов. Например у нас есть недокачанный тайловый кеш окрестностей Парижа. В какой-то момент источник сменил версию тайлов и сервис начал гнать более свежие картинки. Такую ситуацию можно отслеживать и отмечать версию в тайлсете, что позволит не перепутать старые и новые тайлы между собой.
  tileset умеет эффективно сохраняться в бинарный файл и загружаться из него. Состояния тайлов могут задаваться не только целыми числами, но вообще любыми неизменяемыми объектами (в терминологии Питона), например, строками или кортежами. При этом строки занимают место в структуре тайлсета в памяти и на диске только один раз, а в узлах дерева они упоминаются по индексу.
  Кроме всего прочего тайлсет предоставляет итераторы по узлам и по тайлам, статистику о заполнении, методы для одиночной и массовой установки статуса тайлам.

Конечно же, не сделано. как всегда, больше. В ближайших планах:

Для тайлсета

• Итератор по узлам или тайлам определённого статуса.
• Пересечение, вычитание, сложение тайлсетов.
• Фильтры и пастеризация по статусам/набору статусов.
  Из прочего
• Формирование векторных и растровых прозрачных тайлов с текстурой заполнения на основе тайлсета (технически решается обходом фрагмента дерева в глубину, что очень эффективно).
• Создание класса абстрактного тайлохранилища.
• Создание реальных классов тайлохранилищ на основе базы Беркли, sqlite, файловой системы, web-источников и т.д..
• Поддержка в тайлохранилищах многоверсионности тайлов.
• Веб-сервер источник тайлов на основе CGI Python. Планируется реализовать интерфейс тайлохранилища на отдельном веб-сервере с http-доступом посредством обычных get и post запросов. Таким образом можно будет уйти от работы с тайловыми хранилищами и кэшами внутри SAS-планеты и вынести всё это на выделенный или локальный веб-сервер. Это даст возможность использовать один кеш в локальной сети и через интернет, а клиентское приложение (SAS-Планета, например) может сосредоточиться лишь на текущем оперативном кэшировании ближайших тайлов.
• Возможность поставки тайлохранилищем тайлов с маской заполнения.

Желающие поучаствовать в разработке приветствуются. Даже если тяжело, пока что, придумывать эффективный и лаконичный API, можно попробовать себя на поприще написания юнит-тестов.
Юнит-тестирование в таком проекте необходимо как воздух, и связано это, в основном, с непрерывным изменением в ходе разработки реализаций тех или иных механизмов работы библиотеки. Постоянно что-то ломается и следить за всем этим желательно непрерывно, чтобы потом не погрязнуть в рутинной отладке.
Сейчас нужно довести до ума модуль с тестами тайлсета. Модуль Tileid уже более менее покрыт ими.
Прошу к обсуждению с пожеланиями и предложениями.

[Parasite]

На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов.

Версии тайлов (на ГЕ как минимум) уже уехали весьма за 255.
Текущая версия, если не ошибаюсь - 352, and counting.

Создание реальных классов тайлохранилищ на основе sqlite

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

На Mysql из вышесказанного остается только крайне низкая надежность на больших базах даже при выборе журналируемого хранилища INNODB вместо штатного MYISAM. Базы стабильно валятся при числе записей от 400млн и выше (размер базы ок.100Гб), при этом штатными средствами уже не восстанавливаются - необходимо пересоздание с нуля. По совокупности грешков - забросил оба варианта, остановился на нижеследующем.

файловой системы,

Как показывает опыт и долговременное пользование, ЭТО удовлетворяет по всем пунктам.
Из начальных вкусностей - индексирование, журналирование, возможность сохранения более 1 файла в 1 кластер, возможность хранить журнал отдельно от собственно файлокучи (вплоть до удаленного хранения), либо вообще без оного.

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

[svp]

На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов.

Версии тайлов (на ГЕ как минимум) уже уехали весьма за 255.
Текущая версия, если не ошибаюсь - 352, and counting.

Ты, видимо, не понял. 255 различных состояний не ограничивают числом 255 эти самые состояния. Состояние может иметь любое значение, хоть 350, хоть "тристапятьдесят", хоть "2010-12-25". То есть состояния тайлов можно кодировать даже строкой и это не повлияет на производительность тайлсета. Речь шла о том, что в тайлсете (пока что) можно хранить не более 255 РАЗЛИЧНЫХ состояний тайлов. Какими числами, или строками, или кортежами их кодировать -- это не важно. К тому же гугловское понятие этой самой версии -- это плохой пример. На сколько я знаю, версия в гугле опосредованно влияет на выдаваемые тайлы. То есть, когда меняется версия -- это не значит, что обязательно будут заменены все тайлы.
А следовательно этот параметр в тайлсете хранить не имеет смысла вообще.

sqlite

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

Ок. sqlite вычеркиваем.

На Mysql из вышесказанного остается только крайне низкая надежность на больших базах даже при выборе журналируемого хранилища INNODB вместо штатного MYISAM. Базы стабильно валятся при числе записей от 400млн и выше (размер базы ок.100Гб)

Никто не мешает кеш хранить кусками в отдельных базах, скажем, по гигабайту. При наличии механизма (tileset), который может быстро ответить в какой именно базе (т.е. в каком фрагменте хранилища) лежит тот или иной тайл, хранение тайлов во фрагментированном хранилище не представляет проблемы.
Это, кстати, ещё один юзкейс tileset'а. Время обращения к нему, по идее, не зависит от заполненности базы, а в самом тайлсете можно хранить как раз алиасы баз (или в общем случае хранилищ), где хранятся конкретные тайлы.
По-моему, кучка аккуратненьких гигабайтных файлов с тайловыми БД -- это поудобнее, чем миллионы сырых тайлов в файловой системе. В случае же краха отдельной базы мы её стараемся восстановить штатными средствами или перекачиваем невосстановленное.
Тайлсет в таком случае используется следующим образом:
Рассмотрим кеш 19 уровня. Изначально в тайлсете только одна запись, например "http://<чего-то там>maps.google.com/<короче это алиас, намекающий где искать тайлы>". Это означает, что какой бы мы тайл ни запросили у такого тайлсета, он вернёт нам ту самую строку. То есть, пошлёт в гугол.
Дальше мы пытаемся скачать тайл, и есть варианты:
1 - такого тайла не бывает. => В тайлсет по адресу этого тайла кладём статус "отсутствует".

Код: Выделить всё

my_tileset[tile_ident] = ABSENT

2 - гугл отдаёт тайл ==> Тайл кладём в незаполненное ещё хранилище, а в тайлсет улетает строка с алиаом на хранилище.

Код: Выделить всё

storage = get_current_storage()
storage.add(tile_ident, tile_data)
my_tileset[tile_ident] = storage.alias


При этом storage само ведёт свой тайлсет с указанием имеющихся у него тайлов, и если у нас по какой-то причине теряет актуальность my_tileset, то мы его восстанавливаем слив в один тайлсеты всех хранилищ. Алгоритмически это по сути слияние деревьев с максимальной глубиной равной зуму.

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

Код: Выделить всё

storage=sorage_meta_factory(my_tileset[tile_ident])
// в результате получаем либо хранилище-заглушку,
// выдающую всегда один и тот же тайл с надписью об ошибке,
// либо интерфейс к веб-хранилищу а-ля гугол,
// либо наше базадатое хранилище, которое найдено в пуле
// или создано фабрикой sorage_meta_factory по алиасу, извлеченному
// из my_tileset. Не важно что это за хранилище.
tile_data = storage[tile_ident] // уаля: картинка лежит в tile_data


По совокупности грешков - забросил оба варианта, остановился на нижеследующем.

файловой системы,

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

[Parasite]

На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов.

Версии тайлов (на ГЕ как минимум) уже уехали весьма за 255.
Текущая версия, если не ошибаюсь - 352, and counting.

Ты, видимо, не понял.

Возможно, ибо фразу "задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов" я понял как возможность сохранения значения 0...255 выделенном например под версию.
Версии между тем безусловно нужны, и их уже больше 255.
Разобрались. Скип.

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

Это с другой стороны не значит, что при смене версии дерева (глобальном апдейте ГЕ) - версия меняется вообще у ВСЕХ связанных с этим новым деревом тайлов. Она меняется только у нужных, действительно измененных в данном апдейте - хоть в шахматном порядке на слое они расположены, хоть в каком угодно еще. Все же остальные тайлы так и остаются лежать в неизменном виде и по старым УРЛам. В финале же каждый слой представляет из себя мозаику тайлов различных версий (безусловно версия ВСЕХ тайлов меняется только у Q-дерева. Прошел апдейт - ВСЁ Q-дерево поменяло версию по ВСЕМ своим тайлам, а предыдущее - кануло в Лету. Для тайлов контента же - это правило необязательно).

PS: замечено также, что гугль иногда идет кривой и нехорошей дорожкой - иногда меняя версии у тайлов, но не меняя их содержимого. Проверяется по CRC тайлов двух смежных версий. Особенно это касается "апдейтов" ландшафта.

А следовательно этот параметр в тайлсете хранить не имеет смысла вообще.

У гугля версия тайла хранится в имени этого тайла. Каждого отдельно взятого тайла. И дерево ссылается на оные файлы в том числе и по версиям оных.
Будем ли ее хранить мы (т.е. Вы) - дело добровольное, но без ее хранения\учета - в кэше будет зоопарк.

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

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

По-моему, кучка аккуратненьких гигабайтных файлов с тайловыми БД -- это поудобнее, чем миллионы сырых тайлов в файловой системе.

Вышеупомянутый Рейсер, например - это сама по себе БД, и с ней можно работать как с единым файлом. Просто ее фича в том, что ее можно подцепить и как ФС.
Нечто подобное есть и в NTFS (как совокупности обычных файлов $MFT+$Bitmap+$Journal итд - просто винда не дает их видеть как файлы).
То есть, там по большому счету - миллионов сырых тайлов нет. Есть БД, подключенная как ФС. Отсюда возможность писать сколь угодно много файлов в один "кластер" (по существу - в блоб БД), отсюда отсутствие кластеризации, отсюда возможность отлинковки журнала от хранилища, и отсюда же отсутствие дефрагментаторов для рейзера вообще - и все это прозрачно для системы, для нее это "просто винт с файлами".

В случае же краха отдельной базы мы её стараемся восстановить штатными средствами или перекачиваем невосстановленное.

В случае краха мускула мне несколько раз приходилось перекачивать по 100++Гб, ибо любые попытки восстановления наталкивались на "FATAL ERROR: Database is corrupt" и крах собственно базовода. Альтернативные же продукты не понимали INNODB хранилище в оном (по умолчанию там всегда MYISAM, а INNO надо прикручивать ручками если очень хочется).
MYISAM валилось же еще на размерах до гигабайта (неск.млн.записей), так как инсерты при заполнении идут довольно плотно - а журнала в ней нет. ДДОСят.

Также планируется сделать http сервер для расшаривания тайлов в хранилище.
Да, и хранилища можно будет собирать и вкладывать как матрёшки.

Года 3 как пользую такое (и много больше - например калькуляция и отдача авторизации ГЕ, то есть полновесный ГЕ-сервер) в масштабах организации, причем с вариантами: можно голый Перл с форками (если народу мало), можно расово верный и вылизанный Апач с PHP\Перлом (если народу уже неск.тысяч), итд... Все же промежуточные действия с контентом - уже на усмотрение скрипта, а там можно развернуться как угодно (собственно, все вышеупомянутые пляски с базами как раз и были именно на этом этапе).

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

На перле это примерно полстраницы.

Код: Выделить всё

use IO::Socket;
sub get_tile {
$tile=shift;
$tile =~ /(q2|qp|f1|f1c)-(\d+)(-(q.|d.|i.|t.)(\d+)((.|-)(\w+))?)?/;
#Вычисляем путь тайла в кэше
my $path=coord_to_path($2); $tile_path_in_cache=$global_cache.$tiletype."/".$version_in_cache.$path.$tile;

if (-e $tile_path_in_cache) {                             #если файл существует в кэше
        print "Тайла нет в БД, но есть в кэше.\n";
}
else {
        print "Тайла нет ни в БД ни в кэше. Скачиваем тайл с сервера...";
RETRY:
   $status=get_tile();                                    #сходим на сервер и получим тайл в кэш
       if (-e $tile_path_in_cache) {            #обработка результатов получения файла
           print "Ok!\n";
   }
       else {
      print "Получен пустой файл - ждем ".$socket_retry_interval."с и повторяем...\n";
      sleep $socket_retry_interval;
      goto RETRY;
   }
}
return $tile_path_in_cache;
}

sub get_tile {
RETRY_SOCKET:
   $geauth_session=GEsession();$file="/flatfile?".$tile;
   eval {$socket=IO::Socket::INET->new(
         PeerAddr => $http_server,
         PeerPort => $http_port,
         Proto => "tcp",
         Timeout => $socket_timeout)};
      if ($! =~ /timeout/){
         print "|-".$file."\n";
         print "|-обнаружена ошибка сокета TIMEOUT, повтор попытки через ".$socket_retry_interval."с.\n";
         sleep $socket_retry_interval;
         goto RETRY_SOCKET;
      }
      elsif ($! =~ /Unknown/){
         print "|-".$file."\n";
         print "|-обнаружена ошибка сокета UNKNOWN, повтор попытки через ".$socket_retry_interval."с.\n";
         sleep $socket_retry_interval;         
         goto RETRY_SOCKET;         
      }
   if ($socket && $socket->connected()) {
      print $socket "GET $file HTTP/1.0\n";
      print $socket $http_agent;
      print $socket $http_host;
      print $socket $http_connection;
      print $socket "\r\n";
   }
   else {
      sleep $socket_retry_interval;         
      goto RETRY_SOCKET;         
   }
   $store=$tile_path_in_cache;$status=file_store($tile_path_in_cache);         #сохраняем в файл
}


[svp]

Это с другой стороны не значит, что при смене версии дерева (глобальном апдейте ГЕ) - версия меняется вообще у ВСЕХ связанных с этим новым деревом тайлов. Она меняется только у нужных, действительно измененных в данном апдейте - хоть в шахматном порядке на слое они расположены, хоть в каком угодно еще. Все же остальные тайлы так и остаются лежать в неизменном виде и по старым УРЛам. В финале же каждый слой представляет из себя мозаику тайлов различных версий (безусловно версия ВСЕХ тайлов меняется только у Q-дерева. Прошел апдейт - ВСЁ Q-дерево поменяло версию по ВСЕМ своим тайлам, а предыдущее - кануло в Лету. Для тайлов контента же - это правило необязательно).

Таак. Похоже я малость отстал от предметной области. Где почитать обо всех этих Q-деревьях, версиях тайлов и глобальных апдейтах?

PS: замечено также, что гугль иногда идет кривой и нехорошей дорожкой - иногда меняя версии у тайлов, но не меняя их содержимого. Проверяется по CRC тайлов двух смежных версий. Особенно это касается "апдейтов" ландшафта.

Да. Именно так я и планировал расслаивать зоопарки тайлов, только в автоматическом режиме.

У гугля версия тайла хранится в имени этого тайла. Каждого отдельно взятого тайла. И дерево ссылается на оные файлы в том числе и по версиям оных.

Вот и об этом тоже нужно почитать где-то поподробнее. Если информация закрытая, то, пожалуйста, в личку.

Года 3 как пользую такое (и много больше - например калькуляция и отдача авторизации ГЕ, то есть полновесный ГЕ-сервер) в масштабах организации, причем с вариантами: можно голый Перл с форками (если народу мало), можно расово верный и вылизанный Апач с PHP\Перлом (если народу уже неск.тысяч), итд... Все же промежуточные действия с контентом - уже на усмотрение скрипта, а там можно развернуться как угодно (собственно, все вышеупомянутые пляски с базами как раз и были именно на этом этапе).

Да, видимо все эти твои шишки придётся мне собирать с нуля. Перл, ИМХО, негуманный язык. А питоновские скрипты можно будет юзать и на клиенте и на сервере.

[DJ VK]

В программе уже есть четкая структура - папки, в них файлы по 1024 штуки. Новое решение должно предполагать формирование из определенной группы папок одного или нескольких контейнеров, например квадраты 128х128,256х256,512х512 тайлов упакованные в 1 контейнер.
Контейнер должен быть платформонезависимым, и не привязанным к конкретному компьютеру, обмениваться ими должно быть так же легко, как и zip архивами тайлов.
Можно просто разбить по сетке какого нибудь масштаба. 10,11,12 например. (Я использую у себя 11й, 1 квадрат редко превышает 300мб тайлов 18x)
Если сейчас отказаться от квадратичного разбиения начнутся сложности. Я считаю, что предельный размер файла базы данных (1ГБ) - не главный для разбиения на отдельные файлы критерий. Пусть лучше 4 базы по 250мб, но более удобных в плане переноса. файл в 1гб выложить можно не на любой файлообменник.
То, что мобильные яндекс карты также используют мега контейнеры, сформированные именно по квадратам тоже показатель.
Каждую версию также можно класть в отдельный контейнер, собственно манипуляции с каждой новой версией более похожи на манипуляции с новой картой вообще, нужно ли их объединять?
Голоса поделились между базами данных и виртуальными файловыми системами. А какие еще есть варианты контейнеров для хранения групп файлов?

[svp]

В программе уже есть четкая структура - папки, в них файлы по 1024 штуки. Новое решение должно предполагать формирование из определенной группы папок одного или нескольких контейнеров, например квадраты 128х128,256х256,512х512 тайлов упакованные в 1 контейнер.

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

Контейнер должен быть платформонезависимым, и не привязанным к конкретному компьютеру

Библиотека даст возможность унаследоваться от абстрактного хранилища и минимальным количеством кода сделать поддержку хранения тайлов хоть на перфокартах. Основным же моим хранилищем, которое я и буду продвигать, будет BerkeleyDB. Ничего более распространённого для хранения произвольных пар ключ-значение ещё не придумали. Читаем об этом движке в википедии.

Можно просто разбить по сетке какого нибудь масштаба. 10,11,12 например. (Я использую у себя 11й, 1 квадрат редко превышает 300мб тайлов 18x)
Если сейчас отказаться от квадратичного разбиения начнутся сложности. Я считаю, что предельный размер файла базы данных (1ГБ) - не главный для разбиения на отдельные файлы критерий. Пусть лучше 4 базы по 250мб, но более удобных в плане переноса. файл в 1гб выложить можно не на любой файлообменник.

Думаю тут найдётся несколько правильных противоположных мнений на счет правил разбиения кеша на куски. У всех юзкейсы планеты и тайловых кешей разные. Parasite например, захочет иметь огромное хранилище в файловой системе (хотя, думаю, соблазнится когда-нибудь и на беркли), но будет монтировать его ручками или скриптами в баше. При всём уважении я не считаю это удобным вариантом, пригодным для повсеместного использования обычными пользователями=).
Кому-то (мне-например) удобно было бы иметь основное хранилище на домашнем сервере. географическое разбиение кеша по файлам мне там не принципиально, важно, лишь, обеспечить безопасность, коей противоречит хранение всех яиц в одном кармане. Следовательно мне нужны, скажем, гигабайтные файлы с произвольными тайлами внутри, а дефрагментация всего этого хозяйства по координатам будет производиться по мере необходимости. Переносить кеш мне понадобится либо целиком (гигабайтные куски рулят), либо по выбранным полигонам, тогда я просто запущу скрипт, который мне соберёт нужные тайлы в отдельное хранилище.
Хранилище будет поддерживать такой параметр, как размер куска, и ограничения эти будут соблюдаться хранилищем автоматически. Оговорюсь, ничто не мешает написать (или взять готовый) класс для специфического распределения тайлов по суб-хранилищам. Технически это просто потомок от абстрактного РАСПРЕДЕЛИТЕЛЯ с перекрытым методом распределения. метод этот содержит алгоритм, который решает в какое субхранилище положить тот или иной тайл.

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

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

Каждую версию также можно класть в отдельный контейнер, собственно манипуляции с каждой новой версией более похожи на манипуляции с новой картой вообще, нужно ли их объединять?

Ещё раз: новая библиотека будет оперировать понятиями хранилищ, а не контейнеров. Хранилища могут быть вложенными и содержать логику работы с тайлами. На уровне контейнера будут работать специальные контейнерные хранилища, коих может быть написано сколько угодно для любых типов контейнеров.
В первую очередь будут написаны контейнерные хранилища для файловой системы и для базы беркли. На этом уровне одно хранилище -- один файл. Уровнем выше будут агрегатные хранилища, в которых будут регистрироваться хранилища более низкого уровня (например контейнерные) вместе с условиями распределения тайлов. Простейшее условие распределения -- это предельный размер хранилища, более сложные условия могут задаваться с помощью callback функций. Так можно реализовать агрегатное хранилище, которое будет собирать тайлы в отдельные контейнерные суб-хранилища (например по по вашим квадратам 256*256), по мере необходимости, даже, создавая недостающие контейнеры.
Агрегатное хранилище ещё более верхнего уровня может включать в себя ещё и веб-хранилише в режиме read only (например гугл).

Голоса поделились между базами данных и виртуальными файловыми системами. А какие еще есть варианты контейнеров для хранения групп файлов?

Ещё есть вариант написания какого-то самопального велосипеда.
И этот вариант не для меня. Базы данных -- это сказано слишком обобщенно. Базы бывают разными: реляционными или нереляционными, с поддержкой sql, транзакций, журналирования и без. Для нашего случая из стандартных проверенных решений идеальным образом подходит база беркли. Остальное -- это разной степени поделочные обёртки. В случае Паразита это мощная промышленная поделка инженеров, которая работает и приносит профит, а в случае всяких-там зип-контейнеров, трукриптовских разделов, свалки файлов -- это чистой воды наколенное творчество из подпорок и проволочек. Для таких целей есть база беркли. Она для этого придумана.

[Parasite]

Это с другой стороны не значит, что при смене версии дерева (глобальном апдейте ГЕ) - версия меняется вообще у ВСЕХ связанных с этим новым деревом тайлов. Она меняется только у нужных, действительно измененных в данном апдейте - хоть в шахматном порядке на слое они расположены, хоть в каком угодно еще. Все же остальные тайлы так и остаются лежать в неизменном виде и по старым УРЛам. В финале же каждый слой представляет из себя мозаику тайлов различных версий (безусловно версия ВСЕХ тайлов меняется только у Q-дерева. Прошел апдейт - ВСЁ Q-дерево поменяло версию по ВСЕМ своим тайлам, а предыдущее - кануло в Лету. Для тайлов контента же - это правило необязательно).

Таак. Похоже я малость отстал от предметной области. Где почитать обо всех этих Q-деревьях, версиях тайлов и глобальных апдейтах?

Где почитать в виде эссенции - не знаю, благодатных полных ссылок - не встречал. Можно задать вопрос например мне - что знаю, тем поделюсь. Личка доступна, аську тоже знаешь.

Перл, ИМХО, негуманный язык.

Так говорят все виндузятники.
А на нем даже стихи писать можно (параграф ПОЭЗИЯ), и они будут работать как программы.

А питоновские скрипты можно будет юзать и на клиенте и на сервере.

Перл это умеет с рождения.

Parasite например, захочет иметь огромное хранилище в файловой системе

У Паразита уже давно размер тайлового кэша на рейзере приближается к 6Тб только по ГЕ (по контенту, так как фрагментации в рейзере нет), причем физически это разнесено на несколько физических дисков с возможностью раздельной и независимой работы каждого по отдельности (volume stripping).
Единственное, что Паразит действительно ждет от САСа в плане организации сасовского кэша - это учет версионности тайлов САСом. Все остальное Паразит давным-давно имеет собственными силами (включая собственно кэш с версионностью. Но сас работает с ним только через прокси-скрипт, увы).

но будет монтировать его ручками или скриптами в баше

1 строчка в fstab

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

Что может быть проще (в реализации вопроса), чем сборка из тайлового кэша?

Голоса поделились между базами данных и виртуальными файловыми системами.

Вирт.файловые системы - это для пользователей винды (исключительно, и в порядке временной меры - ровно до того момента, пока камрад svp не допилит сабж). В нормальных операционных системах все запрашиваемое давным-давно часть системы (БД как ФС, журналирование транзакций, разбиение и прочая и прочая). Опять же, некто zed ранее в темах этого раздела анонсировал кэш на tar'е - и кажется даже давал какие-то сорцы... А тар тоже допускает разбиение. Ну и тд.
Лично я не голосовал за вирт.файловые системы - я их просто упомянул, как возможные альтернативы пользователям Windows, ибо оная нативно понимает весьма ограниченное число ФС. Лично мне это неактуально.

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