Всеравно нужен индекс id <=> тайл, (osc которые генерят для планеты покамест никто не переделывал, там вроде есть BBOX но он не всегда поможет, т.к. есть правки которые покрывают сразу весь мир). Дальше надо эти индексы (quad-tree и id <=> тайл) синхронизовать.
Нет, это все конечно-же вполне возможно и реализуемо и будучи реализовано существенно упростило бы жизнь разработчикам, но что-то я не вижу толпы добровольцев.
Разница postgresql подхода и OSM подхода, у нас нет скачек PSQL базы данных. Дампы базы разрезать на тайлы еще та сложность. Если мы говорим про distributed database, то они все построены на принципе, что подключение равнозначное и точно не read-only. Самый близкий проект, как ни странно, это Bitcoin - blockchain, распределенная БД платежей. Любой качает дамп, подключается и он в строю и получает мгновенные обновления + любой “доверенный” может контрибутить обратно. Я не говорю, что это perfect match, тут явно не хватает, чтобы можно было скачать дамп некоторого региона, а не всей планеты
Saint_Byte дак там они (тайлы) уже нарезаны. Индекс id-tile прежде всего нужен при построении геометрии линий. Потом запрсы дай мне что-то по id уже не шибко нужны…
В основном это для просмотра комментариев в истории/просмотра тегов которые у объекта сейчас. Т.е. можно кешировать до какой-то разумной степени.
Те кто не любят историю смотреть ничего не заметят, а те кто будет вникать почему что менялось могут остаться без инструментов.
С другой стороны комментарии можно сделать к тайлам?! Но тогда потеряется связь объектами которые комментируют. Это важно при правке скажем админ-границ, чтобы в истории линий добавлялись нужные комментарии.
Я не рассчитываю что такой способ хранения заменит механизм на котором основан API, в лучшем случае я расчитываю поднять реплику планеты, с данными организованными в такую структуру. Соответсвенно история и коментарии мне не нужны. Для получения истории и объекта по id у нас сервисы есть. А вот данных в формате удобном для дальнейшей бработки - нету.
Смотря кто мы, но как сформулировал Виктор, да тайл 2 уровня покрывает четверть планеты, но физически в него записываются лишь те линии/отношения которые полностью лежат внутри этого тайла. Тоесть таких будет немного. Основной объекм данных - это точки раскиданные по тайлам 15 (можно и 16) зума.
И я бы кое-что переделал:
Вопервых, я бы не использовал иерархичность xml’я, мне больше нравится вариант 1 строка - один объект. Закодировать его можно в xml или json.
Вовторых, бы отдельно записывал геометрию и теги. Либо проиндексировал бы точки. Тоесть тайл AAABBB представлял бы из себя папочку с файликами
node.ids node.tags
way.ids way.tags
relation.ids relation.tags
Внутри, на каждой строке, объект. Для ids содержащий лишь айдишки, метаинфу и геометрию
для tags - все целиком.
Над этим я еще подумаю, как лучше, нужен способ быстро “выдрать” id+координаты для всех точек тайла. Это понадобится для построения индекса id-tail
Для инфраструктуры под всем этим, я бы наверное взял hadoop, но надо поработать с ним.
В quad tree применяется техника наложения обычно, 0.55 коэфициент, поэтому все линии закончатся зумом 11 не больше. С другой стороны наложение - это очевидная дубликация данных. Вопрос если мы делаем файл только для чтения и процессинга, дубликация данных не страшна, для редактирование это уже критичнее.
Hadoop я бы не использовал. Слишком сложен в настройке и если решение остается закрытым и не предоставляет открытого API, то как черная коробка ничем не отличается от Postgresql.
Если мы обсуждаем bitcoin blockchain, то наша скорость известная 40МБ osm.gz в день, причем >50% идет на нарост БД. То есть если хранить всю историю правок vs снепшот последнего, то разница не такая критичная предполагаю раза в 3 больше. В Биткоине блок составляет 0.6МБ и их происходит около 144 в день, т.е. размер около 100 МБ в день, что сравнимо c OSM.
Дак а причем тут биткоин и блокчейн? Биткоин это distributed hash table + цепочка подписей.
Писать свой DHT? Тут куча вопросов как это написать и без разработки своего алгоритма DHT сети. И без DHT есть сомнения что это кто-то в бозримом будущем реализует, а если еще и самим кластеризацию колхозить - это не взлетит никогда.
Тогда надо ограничиваться каким нибудь 10 зумом, да и то получим необходимость хранить 100500 этих тайлов для всех данных, это явный минус против одного.