Можно ли использовать sqlite для хранения тайлов от карты?

Question

[Дмитрий Бондаренко]

Привет!
Сейчас у меня тайлы для карты хранятся в FileDB .
Вот этот сервис хранит тайлы для карт в базе sqlite3 в виде BLOB. Не тестировал еще производительность, однако утилита Maperitive, которую я использую для генерации тайлов поддерживает такой "формат". Однако, при генерации умудрилась упасть производительность до 3-4 тайлов в секунду на 13м уровне (против генерации около 50 тайлов в секунду в виде картинок).

Сейчас генерируется 14й уровень зума - почти 2 миллиона картинок. Планирую нагенерировать до 17 включительно. Потянет ли БД такие объемы данных - ориентировочно это 128 миллионов тайлов, объем около 106 гигабайт?
Тут я должен сделать несколько сносок -
- пока что картинки в PNG, сейчас буду тестировать JPG, если будет меньше места занимать - буду его использовать.
- на данный момент не реалізовано хеширование и удаление одинаковых картинок из базы, т.е. если 100 тыщь картинок имеют морскай фон - это можно описать всего 1й картинкой
- 17й уровень зума - это план. Генерирую по 1му уровню, а там будет видно.

А может быть для сего что-то существует уже готовое?
Платформа - WinRT, оффлайн карта в приложении, приложение для внутреннего использования сотрудниками на выезде. В теории, если софт будет работать в офисе - организую TileServer для сетевой работы. Так же если планшет "находит" локальную сеть или "качественный" интернет - можно организовать подгрузку с TileServer'a остальных недостающих данных.

Comments

[Дмитрий Бондаренко]

К сожалению, с генерацией какие-то проблемы. Генерация с помощью Maperitive очень и очень медленная. 15й уровень генерируется уже 2е сутки, даже 40% нет.
По ходу дела обнаружилось огромное количество одинаковых картинок, которые нужно будет отфильтровать (перекресные ссылки, т.е. в базу добавляется один тайл с белым фоном, все остальные тайлы, которые так же само выглядят будут ссылаться именно на этот уникальный тайл).

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

Копаю в сторону мапника.

Answer 1

[gleb_kudr]

По объему потянет. По структуре - обязательно выносите все ключи в отдельную базу, в картинках ничего не ищите, только берите уже по известному адресу. Ну и надо помнить про однопоточную работу базы. Если это устраивает, то вперед.

Comments

[Дмитрий Бондаренко]

Спасибо! Я пока что использовал готовую FileDB, но начались проблемы - почему-то рендомно на больших объемах стали исчезать данные, пишется пустое место в файл и все. Сурцов нет, либа обфусцирована. Так что вернулся к вопросу с кастомной схемой реализации.

Сделаю так - SQLite база с метаданными тайлов (key\length\seekposition\etc) и паралельно ей просто файл где друг за другом записаны картинки. Думаю, вполне просто, масштабируемо и платформо не зависимо.

Answer 2

[evnuh]

This particular upper bound is untested since the developers do not have access to hardware capable of reaching this limit. However, tests do verify that SQLite behaves correctly and sanely when a database reaches the maximum file size of the underlying filesystem (which is usually much less than the maximum theoretical database size) and when a database is unable to grow due to disk space exhaustion. From https://www.sqlite.org/limits.html .