Лет 7 назад я работал с SQLite3 и неприятно для себя обнаружил, что эта субд поднимается из дампа и ПОЛНОСТЬЮ висит в ОЗУ (т.е. объем в памяти = размеру дампа), периодически сбрасывая данные обратно в дамп. Там не было как, например, в PostgreSQL в момент выполнения select обращения к файлам, а в памяти хранятся только индексы. Может я тогда плохо сконфигурировал, может тогда sqlite3 не умел не весь подниматься в память. Точно так же работает Redis. Только оперативки сейчас у меня много, да и no-sql субд работает всегда немного быстрее любых sql-субд за счет отсутствия необходимости поддержки sql синтаксиса.
Между прочим весьма распространенный формат карт mbtiles работает в СУБД sqlite3, которая, насколько мне известно, вся висит в памяти при работе. У них тоже пустая трата памяти? Память — это быстрый доступ к данным, а также возможность продлить ресурс жесткого диска, который явно будет служить меньше, если постоянно дергать файлы.
Это прекрасно, что предусмотрено. Но укажите хоть один ресурс, в котором говорится, что задублированы 60-70-80-90% тайлов? Неужели и это всем известно?
Я пытаюсь реализовать Ваш способ #2. У меня возникло несколько вопросов:
1. Для связки tirex+ngunx вы использовали lua модуль nginx-lua-osm от японского разработчика Hiroshi Miura?
2. Под какую ось это сооружалось?
3. Apache при этом не нужен?
4. Правильно ли я понимаю, что tirex нужен для организации метакэша, а mod_tile для управления очередью рендеринга и самого рендеринга с помощью mapnik'а?
4. Подскажите хороший мануал по настройке Вашего способа #2.
На случай ребута лучше иметь парочку таких серверов и настроенный балансировщик, которому на время ребута одного из серверов необходимо указать использовать только оставшуюся рабочую машину.
По поводу терабайт. Я рассматриваю вариант размещения в RamFS тайлов до 17-го масштаба (по моим подсчетам около 1,3ТБ). Да, это много, но нынче оперативка относительно дешевая (главное, чтобы проект этого стоил :) ).
Есть еще несколько мыслей по поводу оптимизации размера tile storage. Если размещать данные, например, в Redis'е (т.е. тоже в оперативке), а не в файловой системе (даже в TmpFS), то удается сэкономить около 30% емкости за счет отсутствия необходимости хранить каталоги (которые в файловой системе, как известно, тоже занимают определенный размер), отсутствия проблем с незаполнением блоков, т.е. за счет более эффективного использования ресурса (оперативки по сравнению с файловой системой). Кстати, Redis умеет реплицироваться, что существенно упрощает решение проблемы разворачивания/ребута еще одного сервера, участвующего в балансировке.
Еще я заметил, что до 70% тайлов дублируются (проверял по контрольной сумме SHA1). Как правило, это океаны, пустыни и пр. Т.е. так называемые Empty Tiles по 103 байта. Даже на этом можно попытаться сэкономить место. Например, symlink в среднем занимает 20 байт, т.е. до 70% тайлов можно в пять раз компактнее хранить, что примерно составляет около 50% емкости tile storage. Другое дело, что вычислять контрольную сумму — дело дорогостоящее для миллиардов тайлов. Пока это только мои исследования. Возможно, позже напишу статью на Хабре о результатах.
P.S. Все время не покидает ощущение, что я хожу хоженными тропками, горожу велосипед и т.п., но, к сожалению, мудрость черпать неоткуда, кроме как из ваших скудных (да простите меня за откровенность) ответов.
Интересно какую файловую систему выбрала команда Спутника для тайлового хранилища. У меня Empty Tile занимает 103 байта. На блочной файловой системе с большим блоком это расточительно…
Подскажите, а какую файловую систему вы выбрали для хранения тайлов?
Из статьи неясно как Вы кодируете/декодируете последовательность обхода городов коммивояжером. Как нолики и единицы хромосомы становятся номерами городов?
Кодирование числа с плавающей точкой давно уже описано в литературе. Если коротко, то выбирается допустимый диапазон значений float, разбивается на N интервалов таким образом, чтобы два соседних интервала давали приблизительно одинаковое значение фитнес-функции. Тогда число с плавающей точкой однозначно отображается в номер интервала. И наоборот, по номеру интервала можно вернуться к значению с плавающей точкой. Теоретически N можно сделать бесконечно большим, чтобы дискретность числа с плавающей точкой была незаметна, но тогда увеличивается длина хромосомы, что увеличивает алгоритмическую сложность задачи. Поэтому N выбирается с умом.
Теперь о практике. Я реализовывал генетический алгоритм применительно к дискретной задаче о рюкзаке. Но я его вдоль и поперек исследовал и для непрерывных функций. Результаты превзошли все мои ожидания. Для сложных целевых функций генетический алгоритм всегда выдавал абсолютный экстремум. Если попытаться решать ту же задачу градиентным спуском, то хотя и не будет потерь на кодировании/декодировании хромосомы, но гарантии нахождения абсолютного экстремума нет.
Подскажите какие ключи Вы используете для osm2pgsql, что импорт у Вас занимает всего 12 часов. Я лично почувствовал эффективность --drop и --unlogged. Остальные настройки иногда даже ухудшали время импорта.
В рамках моих профессиональных интересов меня интересует не сама возможность работать с полной базой, а возможность сгенерировать тайлы вплоть до 17-го масштаба. Это однократная задача. Я лишь периодически перегенерирую тайлы, например, Москвы, когда, например, разобрался как рисовать станции метро с «правильными» картинками.
Другое дело, что меня интересует возможность строить маршруты с помощью PgRouting. Вот тут не обойтись без хорошего железа. Но пока мои поиски не привели хотя бы к одному успешному проекту, где импортировался бы весь Planet.osm. А по частям/регионам догружать стандартный osm2pgrouting не умеет. Может Вы чего посоветуете?
Я, кстати, связывался с разработчиками Спутника по данному поводу. Они мне тогда отвечали, что для карт, курпнее 9-го масштаба, для данных OSM используют теги name:ru. Если в базе нет русских названий — добавляют вручную. Но если посмотреть на их карты, то там очень много добавлено переводов по сравнению с тем, что я получил для того же Китая, взяв уже имеющиеся переводы.
Кстати, я искал не только дампы баз, но и сгенерированные тайлы в архивах. Но тоже не нашел. К слову, размер тайлов на весь Земной шар до 19-го масштаба составляет около 5,5ТБ. Это то из PBF файла размером всего то 18,5ГБ.
Есть еще аргументы в пользу OpenStreetMap, например, возможность реализации оффлайного тайлового сервера, в закрытых сетях, без доступа к данным серверов (Яндекса, Гугла и даже OpenStreetMap'а), или в случае обрыва связи с упомянутыми серверами (хотя бы из-за санкций :) ). Без собственного тайлового сервера Вы не сможете это реализовать. Вот тут-то список возможных реализаций веб-карт сильно проредеет.
Ваши аргументы уходят за границы данной статьи. Но Вам скажу, что использование Яндекс-карт как и Гугл-карт ограничено лицензионным соглашением, которое имеет свои «особенности» для юр.лиц., в т.ч. по количеству запросов к серверам (тайловым, геокодера и т.п.). В этом смысле OpenStreetMap не ограничивает разработчиков, особенно если Ваш ресурс высоконагруженный (более 1 млн.запросов в сутки). Но выбор реализации веб-карт — это выбор разработчика. Решать Вам.
Я искал, но к сожалению не нашел. Возможно у Вас получится лучше. Но я думаю не просто же так OpenStreetMap распространяет данные карт в форматах PBF и OSM XML, а не pg_dump-овские файлы. Наверное, есть тому причины. Предположу, что есть проблемы с версионностью Postgres'а и PostGis'а. Чтобы дамп без ошибок перелился, надо версии иметь совпадающие. При несоответствии версий кто поручится за целостность восстановления базы из дампа?
1. Для связки tirex+ngunx вы использовали lua модуль nginx-lua-osm от японского разработчика Hiroshi Miura?
2. Под какую ось это сооружалось?
3. Apache при этом не нужен?
4. Правильно ли я понимаю, что tirex нужен для организации метакэша, а mod_tile для управления очередью рендеринга и самого рендеринга с помощью mapnik'а?
4. Подскажите хороший мануал по настройке Вашего способа #2.
По поводу терабайт. Я рассматриваю вариант размещения в RamFS тайлов до 17-го масштаба (по моим подсчетам около 1,3ТБ). Да, это много, но нынче оперативка относительно дешевая (главное, чтобы проект этого стоил :) ).
Есть еще несколько мыслей по поводу оптимизации размера tile storage. Если размещать данные, например, в Redis'е (т.е. тоже в оперативке), а не в файловой системе (даже в TmpFS), то удается сэкономить около 30% емкости за счет отсутствия необходимости хранить каталоги (которые в файловой системе, как известно, тоже занимают определенный размер), отсутствия проблем с незаполнением блоков, т.е. за счет более эффективного использования ресурса (оперативки по сравнению с файловой системой). Кстати, Redis умеет реплицироваться, что существенно упрощает решение проблемы разворачивания/ребута еще одного сервера, участвующего в балансировке.
Еще я заметил, что до 70% тайлов дублируются (проверял по контрольной сумме SHA1). Как правило, это океаны, пустыни и пр. Т.е. так называемые Empty Tiles по 103 байта. Даже на этом можно попытаться сэкономить место. Например, symlink в среднем занимает 20 байт, т.е. до 70% тайлов можно в пять раз компактнее хранить, что примерно составляет около 50% емкости tile storage. Другое дело, что вычислять контрольную сумму — дело дорогостоящее для миллиардов тайлов. Пока это только мои исследования. Возможно, позже напишу статью на Хабре о результатах.
P.S. Все время не покидает ощущение, что я хожу хоженными тропками, горожу велосипед и т.п., но, к сожалению, мудрость черпать неоткуда, кроме как из ваших скудных (да простите меня за откровенность) ответов.
Подскажите, а какую файловую систему вы выбрали для хранения тайлов?
Теперь о практике. Я реализовывал генетический алгоритм применительно к дискретной задаче о рюкзаке. Но я его вдоль и поперек исследовал и для непрерывных функций. Результаты превзошли все мои ожидания. Для сложных целевых функций генетический алгоритм всегда выдавал абсолютный экстремум. Если попытаться решать ту же задачу градиентным спуском, то хотя и не будет потерь на кодировании/декодировании хромосомы, но гарантии нахождения абсолютного экстремума нет.
Другое дело, что меня интересует возможность строить маршруты с помощью PgRouting. Вот тут не обойтись без хорошего железа. Но пока мои поиски не привели хотя бы к одному успешному проекту, где импортировался бы весь Planet.osm. А по частям/регионам догружать стандартный osm2pgrouting не умеет. Может Вы чего посоветуете?