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 этих тайлов для всех данных, это явный минус против одного.
Для всех задач сразу и с голубой каёмочкой не оптимизируешь.
Админ границы - нужны вроде бы всем разработчикам.
POI, детали городов - нужны миллионам пользователей “поверх” разработчиков
Логичнее что для “только админ границ” сделать отдельный специальный сервис. Я забыл ссылку прямо сейчас есть немецкий сервис выгрузки шейпфайлов по admin_level. Там даже интрерфейс с деревом и галочками для скачивания сделали.
На самом деле самый просматриваемый по количеству тайлов зум это 17, 18 - в разы меньше, 19 смотрят единицы, но возможно если бы адреса начинались с 16, то статистика была бы немного другой. Стоит учитывать что тайлов 17 вчетверо больше чем 16, а просмотров больше процентов на 30, это я к тому что количество тайлов растёт быстрее чем количество просмотров на зум. Статистика тайлов с osm.org ограничивается 0-19 зумами.
Допустим 17 сейчас самый популярный, давайте для него в первую очередь оптимизировать.
зум пользователя зависит
от стиля
от самих данных на этом зуме (нет ничего нового на 18 - не буду приближать)
Т.е. если 17-19 это один стиль, то мы должны говорить о 19 в том числе. 18 и 19 не смотрят потому что ничего нового и пользователи “привыкают” к этому.
Нужно смотреть не только статистику но и хотелки пользователей, пользователям всегда нужны POI на низких уровнях (не важно какие конкретно цифры).