Организовать работу веб-карт с помощью технологии Скользкая карта требуется организовать тайловое хранилище, в котором тайлы могут быть предварительно отрисованы (сгенерированы) в предопределенном контексте карты, или может использоваться набор сервисов для генерации тайлов по запросу, или некий симбиоз первых двух подходов.
Первый подход имеет тот недостаток, что требует слишком большого объема памяти для тайлов.
Итак, согласно OpenstreetКарта по состоянию на март 2011 г.
требовалось 54 ТБ дискового пространства.
По моим расчетам, по текущим данным на июнь 2015 года этот показатель уже составляет около 100ТБ (это лишь оценка, на реальный эксперимент я не рискнул) для хранения тайлов масштабов 0.17. Такой «рост» оценок связан с тем, что за прошедшее время данные OpenStreetMap значительно расширились, детализировались пустующие в марте 2011 года территории.
Мы также не можем сбрасывать со счетов неоптимальное сжатие (в моем случае по сравнению с OpenStreetMap) формата PNG (мой средний размер плитки составляет 4,63 КБ против 4,63 КБ).
633 байта OpenStreetMap в марте 2011), сложность стиля рисовки мапника и другие мои нюансы.
В любом случае для хранения тайлов требуется МНОГО места, что не каждый сервер может себе позволить.
Ситуация усугубляется еще и тем, что для блочных файловых систем небольшие тайлы занимают целый блок (тайл размером 103 байта может занимать целый блок, например, 4 КБ), что приводит к неэффективному использованию физического пространства жесткого диска.
При большом количестве тайлов (для крупномасштабных карт) в пределах одного каталога все равно может возникнуть проблема с невозможностью хранения необходимого количества файлов или большего количества каталогов, чем позволяет файловая система.
Но при всем при этом такой подход обеспечивает комфортное время выполнения запроса на возврат плитки.
Второй подход хоть и не требователен к мощности тайлового сервера, но требует организации и обслуживания нескольких сервисов (PostgreSQL, Postgis, HStore, mapnik, renderd, mod_tile, apache), которые бы надежно генерировали и доставляли тайл запрошенному клиентскому сервису.
Также необходимо периодически очищать тайловый кэш.
Другими словами, платой за небольшую емкость жесткого диска тайлового сервера является сложность архитектуры и значительное время выполнения запроса на возврат каждого конкретного тайла (по моим расчетам, до 500мс всего на 1 клиент ; для высоконагруженного сервиса это время может вырасти до неприемлемых значений).
В этой публикации я не касаюсь вопросов архитектуры тайлового сервера.
В конечном счете, вам решать, как вы будете создавать свой собственный картографический веб-сервис, начиная с аппаратного обеспечения вашего сервера.
В этой статье я просто хочу обратить внимание на некоторые особенности тайлового хранилища, зная которые вы сможете оптимально построить свой веб-картографический сервис.
Кстати, я решил построить свой картографический веб-сервис на основе смешанного подхода.
Дело в том, что география обращений пользователей моего веб-сервиса довольно четко определена.
Те.
Я заранее знаю контекст карты, который будут запрашивать пользователи, что позволяет мне предварительно визуализировать фрагменты в заданном контексте карты.
В моем случае объем необходимых тайлов составил 511ГБ для масштабов 3.17. При этом для масштабов 3.13 я генерировал все тайлы, не отталкиваясь от заранее известного мне контекста карты.
Привожу статистику количества и объёма сгенерированных тайлов по масштабу карты.
| Шкала | Всего создано плиток | Всего плиток для масштаба (4^увеличение) | Доля в % от общего количества плиток | Объем сгенерированных тайлов | Общий объем плиток для масштаба | Доля в % от общего объема плитки |
|---|---|---|---|---|---|---|
| 3 | 64 | 64 | 100 | 1,3 млн.
|
1,3 млн.
|
100 |
| 4 | 256 | 256 | 100 | 4,3 млн.
|
4,3 млн.
|
100 |
| 5 | 1 024 | 1 024 | 100 | 15М | 15М | 100 |
| 6 | 4 096 | 4 096 | 100 | 50М | 50М | 100 |
| 7 | 16 384 | 16 384 | 100 | 176М | 176М | 100 |
| 8 | 65 536 | 65 536 | 100 | 651М | 651М | 100 |
| 9 | 262 144 | 262 144 | 100 | 1,7 г | 1,7 г | 100 |
| 10 | 1 048 576 | 1 048 576 | 100 | 6,1 г | 6,1 г | 100 |
| 11 | 4 194 304 | 4 194 304 | 100 | 18Г | 18Г | 100 |
| 12 | 16 777 216 | 16 777 216 | 100 | 69Г | 69Г | 100 |
| 13 | 67 108 864 | 67 108 864 | 100 | 272Г | 272Г | 100 |
| 14 | 279 938 | 268 435 456 | 0.10 | 3,2 г | 1,1Т | 0.29 |
| 15 | 1 897 562 | 1 073 741 824 | 0.18 | 15Г | 4,35Т | 0.34 |
| 16 | 5 574 938 | 4 294 967 296 | 0.13 | 34Г | 17,4Т | 0.19 |
| 17 | 18 605 785 | 17 179 869 184 | 0.11 | 94Г | 69,6Т | 0.13 |
| Общий | 115 842 662 | 366 503 875 925 | 0.51 | 511Г | 92,8Т | 0.51 |
Например, в океане две соседние плитки выглядят одинаково синими.
Но визуально идентичные и бинарно идентичные тайлы — это разные вещи.
Проверяя свою гипотезу, я сравнил контрольные суммы MD5 двух соседних плиток и они оказались одинаковыми.
Означает ли это, что все тайлы уникальны с контрольной суммой MD5? Конечно, нет!root@map:~# md5sum 10/0/0.png a99c2d4593978bea709f6161a8e95c03 10/0/0.png root@map:~# md5sum 10/0/1.png a99c2d4593978bea709f6161a8e95c03 10/0/1.png
Есть такая вещь, как столкновения .
Те.
два визуально (в том числе двоичных) разных тайла могут иметь одинаковую контрольную сумму.
Такой риск есть, хотя для файлов произвольного размера он невелик.
Поскольку веб-карты — это ресурс, который, как правило, не требует абсолютной точности (в отличие, например, от банковских транзакций или котировок Форекс), мы примем, что низкая вероятность столкновений плиток — это приемлемый риск, оправдывающий.
Почему нам действительно важно знать, что существуют тайлы с одинаковой хэш-функцией? Вы, наверное, уже догадались.
Зачем хранить несколько одинаковых тайлов и занимать ими свой жёсткий диск, если можно хранить только один файл и какое-то отображение на него всех дубликатов (например, с помощью банальной симлинка)? Таким образом, низкая вероятность коллизий тайлов является приемлемым риском, оправдывающим снижение требований к емкости хранилища тайлов.
Но какую выгоду мы получим от удаления всех дубликатов? По моим подсчетам, до 70% плиток дублируются.
Причем, чем больше масштаб, тем больше эта цифра.
Надо отметить, что я не первый додумался исключить дублирование тайлов с помощью хэш-функции.
Да, команда Спутник Этот нюанс я использовал для оптимальной организации тайлового кэша.
Также в обычном формате МБтайлы Решена проблема дедупликации тайлов.
Ниже в таблице и на рисунке я привожу статистику по найденным дубликатам (по MD5) тайлов.
| Шкала | Всего ген.
плитка |
Всего дубликатов плиток | Количественная доля в % д.б.
плитка |
Плитки объема генов | Объем тайлов после создания символических ссылок | Объем.
доля в % д.б. плитка |
|---|---|---|---|---|---|---|
| 3 | 64 | 0 | 0 | 1,3 млн.
|
1,3 млн.
|
0 |
| 4 | 256 | 10 | 3.91 | 4,3 млн.
|
4,2 млн.
|
0.92 |
| 5 | 1 024 | 80 | 7.81 | 14,6 млн.
|
14,3 млн.
|
2.13 |
| 6 | 4 096 | 659 | 16.09 | 49,7 млн.
|
47,1 млн.
|
5.18 |
| 7 | 16 384 | 4 058 | 24.77 | 175,4 млн.
|
159,6 млн.
|
9.04 |
| 8 | 65 536 | 23 031 | 35.14 | 650,3 млн.
|
560,3 млн.
|
13.83 |
| 9 | 262 144 | 184 668 | 70.45 | 1710М | 989М | 42.18 |
| 10 | 1 048 576 | 767 431 | 73.19 | 6,1 г | 3,1 г | 48.22 |
| 11 | 4 194 304 | 3 553 100 | 84.67 | 18Г | 4,4G | 75.41 |
| 12 | 16 777 216 | 14 797 680 | 88.18 | 69Г | 12,4 г | 82.01 |
| 13 | 67 108 864 | 60 945 750 | 90.82 | 271,1Г | 38,7 г | 85.74 |
| 14 | 279 938 | 47 307 | 16.9 | 3,2 г | 185М | 5.71 |
| 15 | 1 897 537 | 514 005 | 27.09 | 14,2 г | 12,3G | 13.78 |
| 16 | 5 574 938 | 1 934 553 | 34.70 | 33,8 г | 26,4 г | 21.86 |
| 17 | 18 605 785 | 8 312 466 | 44.68 | 93,8 г | 62Г | 33.82 |
| Всего изменить | 115 842 662 | 91 084 800 | 78.63 | 511Г | 164Г | 32.07 |
Пожалуйста, имейте в виду, что:
- Я генерировал тайлы в контексте крупных городов, что само по себе ухудшает показатель дублирования тайлов, потому что в крупных городах меньше шансов встретить два одинаковых тайла, чем в море.
Поэтому данные по шкалам 3.13 показывают степень дублирования тайлов для всего земного шара, а данные по шкалам 14.17 показывают дублирование только в разрезе крупных городов.
- Я создал тайлы масштабов 3.10 с помощью одного файла стиля Mapnik, а тайлы 11.17 - с другим файлом стиля.
Более того, разные правила стилей рисования работают в разных масштабах, что приводит к неоднородности рисования тайлов в разных масштабах.
Это обстоятельство вносит некоторый шум в статистику.
- Как правило, дублируются так называемые Empty Tiles, имеющие размер всего 103 байта.
Поэтому существенного уменьшения размера тайлового хранилища ожидать не следует, как показывают данные на масштабах 9.12. В среднем при коэффициенте дублирования тайла 70% удается уменьшить размер каталога масштабирования всего до 50%.
- Из-за случайности выбора исходного тайла статистика масштаба зашумлена, т.е.
если один и тот же тайл встречается на 10-й и 12-й шкалах, то приняв за исходный тайл масштаба 10, тайл масштаба 12 будет считаться тайлом.
дублировать, и наоборот. В зависимости от того, как был классифицирован тайл, это внесет шум в статистику соответствующего масштаба.
В связи с этим в таблице по линиям шкалы присутствует некоторый элемент случайности.
Только линия заслуживает абсолютного доверия "Общий".
Сначала вы будете использовать файловую систему, которая уже установлена в вашей системе.
Но когда вы столкнулись с большими объемами данных, столкнулись с чрезмерным дублированием тайлов, столкнулись с проблемами длинных ответов файловой системы при параллельных запросах и рисками выхода из строя этих дисков, то вы наверняка задумаетесь о том, КАК разместить тайлы.
тайловый кэш.
Как правило, тайлы имеют небольшой размер, что приводит к неэффективному использованию дискового пространства на блокировать файловые системы , а большое количество тайлов вполне вероятно может использовать все свободное количество i-узлов.
Если вы уменьшите размер блока до любого небольшого размера, это повлияет на максимальную емкость хранилища, поскольку любая файловая система обычно ограничена максимальным количеством i-узлов.
Даже заменив дублирующиеся тайлы символическими ссылками, вы не сможете существенно уменьшить требуемую емкость хранилища тайлов.
Частично проблему незаполненных блоков можно решить с помощью механизмов метатайлинга — несколько тайлов (обычно 8х8 или 16х16) хранятся в одном файле, имеющем специальный заголовок, анализируя который, можно понять, из какого байта находится нужный тайл.
.
Но метатайлы, к сожалению, сводят усилия по дедупликации тайлов на нет, потому что вероятность встретить два одинаковых метатайла (по набору N x N тайлов) существенно снижается, а сам формат заголовка (первые 532 байта для метатайла размером 8 x 8 тайлов) метатайла предполагает запись адреса метатайла, что делает его уникальным и, следовательно, исключает возможность дедупликации в принципе.
Но тем не менее сегодня использование метатайлинга позволяет «предсказать» запрос соседних тайлов, а значит, сократить время ответа тайлового сервера.
В любом случае для хранения плитки необходимо соблюдать ряд условий:
- обеспечить эффективное использование дискового пространства, чего можно добиться за счет уменьшения размера блока блочной файловой системы,
- обеспечить поддержку большого количества файлов и каталогов
- обеспечить максимально быструю доставку плитки по запросу
- устранить дублирование плиток
При этом он не имеет встроенной поддержки операционных систем Linux (из-за несовместимости лицензий GPL и CDDL) и создает повышенную нагрузку на процессор и оперативную память (по сравнению с традиционными ExtFS, XFS и т.п.
).
, что является следствием его полного контроля над физическими и логическими носителями.
Файловая система BtrFS более дружественна к Linux, поддерживает дедупликацию (оффлайн), но все еще очень сырая для производственных систем.
Существуют и другие решения, позволяющие исключить дублирование плиток и максимально эффективно использовать дисковое пространство.
Практически все они сводятся к созданию виртуальной файловой системы и подключению к ней специальных сервисов, позволяющих обращаться к этой виртуальной файловой системе, дедуплицировать файлы на лету, а также размещать и отправлять их в/из кэша.
Например, UKSM, LessFS, NetApp и многие другие реализуют дедупликацию данных на уровне сервиса.
Но в продакшене беспорядок сервисов чреват большими проблемами, особенно на высоконагруженных веб-сервисах.
Поэтому выбор архитектуры полистного кэша для производства должен быть сверхотказоустойчивым и простым в администрировании.
Известный спутник (да простят меня вышеупомянутые разработчики — этот проект стал для меня своеобразным положительным примером, на основе которого я строю свой веб-картографический сервис) реализует собственный алгоритм дедупликации, который также использует некую хеш-функцию, позволяющую дедупликацию плитки, а сами плитки хранятся в гибком CouchBase. Я также пытался создать что-то подобное, используя инструменты, которым я доверял в производстве.
В данном случае мой выбор пал на Redis. Мой опыт показал, что при размещении тайлов в памяти Redis можно добиться сокращения объёма потребляемой памяти на 30% по сравнению с размещением в файловой системе.
Вы можете подумать: зачем использовать Redis? Ведь он живет в ОЗУ? Мой выбор обусловлен несколькими причинами.
Прежде всего надежность.
За год работы Redis зарекомендовал себя как очень надежный и быстрый инструмент. Во-вторых, теоретически ответ из памяти происходит быстрее, чем ответ из файловой системы.
В-третьих, стоимость оперативной памяти для серверов стала сравнительно невысокой, а надежность жестких дисков за последние годы особо не улучшилась.
Те.
интенсивная работа сервера с жестким диском (как это происходит при передаче тайлов) значительно увеличивает риск его выхода из строя.
Кроме того, в моей организации имеется около 100 серверов по 515ГБ ОЗУ каждый (но с небольшими жесткими дисками), что позволяет эффективно размещать тайлы в памяти (при правильном проксировании zxy --> конкретного сервера).
Так или иначе, мой выбор пал на Redis. Я не навязываю это моему дорогому читателю.
Вы можете самостоятельно определиться с архитектурой собственного картографического веб-сервиса.
У этой статьи была только одна цель — рассказать о некоторых недокументированных нюансах картографических веб-сервисов.
ЭСэкономьте свое время и деньги благодаря моей, надеюсь, не бесполезной исследовательской работе! Теги: #Хранилище плиток #контрольная сумма #символическая ссылка #redis #открытый исходный код #OpenStreetMap #API карт
-
Arm Cortex M* — Сколько «Весит» Примитив?
19 Oct, 24 -
Необходимый Ремонт Компьютерной Периферии
19 Oct, 24
