Разница 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 этих тайлов для всех данных, это явный минус против одного.