ObjectManager, или как работать с большим количеством объектов на карте, Марина Степанова (Яндекс)

ObjectManager или как
работать с действительно
большим количеством
объектов на карте
Марина Степанова,
Яндекс

О чем поговорим
• Почему сложно показать много точек на
карте, обзор решений
• Как отрисовать большое количество меток на
клиенте
• Загрузка меток по требованию
• Организация хранения и обработки данных
на сервере

Почему сложно хорошо показать
много меток на карте?

Решаем задачу «в лоб»
Сервер
page.html

page.html
<!DOCTYPE html>
<html>
<head>
<script src="//api-maps.yandex.ru/2.1/?lang=ru_RU"
type="text/javascript"></script>
<script type="text/javascript">
ymaps.ready(function () {
var myMap = new ymaps.Map('map', {
center: [55.76, 37.64],
zoom: 10
});
});
</script>
</head>
<body><div id="map"></div></body>
</html>

А теперь добавим метки!

Очевидные недостатки
• page.html весит несколько Мб и страница
долго загружается
• Мы передаем на клиент слишком много
данных
• Мы рисуем на клиенте данные, которые
пользователь может не видеть

Что предлагалось
пользователям многие годы?*
*Не только в API Яндекс.Карт

Решение №1 – активные области

Решение №1 – активные области
Плюсы Минусы
Очень быстрый
рендеринг на клиенте
Оооочень сложная
серверная часть
Передаются только
данные для видимой
области
Клиентская картинка
абсолютно статична

Решение №2 - кластеризатор

Решение №2 – кластеризатор
Просто использовать Клиент тратит время на
кластеризацию
Дизайн определяется и
настраивается на
клиенте
Не решена проблема
оптимальной загрузки
данных

X 50 000
new ymaps.Placemark([45.3, 25.45])
50 000

X 50 000
50 000
Лишние программные
инициализации

Что нужно в идеале?
• Никаких лишних инициализаций на
клиенте
• Запрашиваем данные пачками асинхронно
• Передаем на клиент только данные,
которые видит пользователь
• Рисуем на клиенте только данные, которые
видит пользователь

Что мы сделали для клиентской
оптимизации

Храним только данные
• Все данные хранятся как их JSON-
описания в специальном менеджере
• Программные сущности создаются только
при необходимости нарисовать объект

X 50 000
50 000
Храним только данные

Как ускорить геообъекты?

Balloon
Hint
Editor
Options
Events
Overlay
…

Balloon
Hint
Editor
Options
Events
Overlay
…
Компонент, отвечающий
непосредственно за
отрисовку на карте

ObjectCollection
Balloon
Hint
Editor
Options
Events
…
Overlay Overlay Overlay

Получился ObjectManager
• Хранит данные и не создает программные
сущности без надобности
• Мы вынесли всю инфраструктуру в общую
коллекцию, в метках оставили только самое
нужное
https://clck.ru/9LqPp

Время добавления на карту меток с
кластеризацией
6000
5000
4000
3000
2000
1000
0
1000 10000 50000
ObjectManager
Placemarks

Поговорим про загрузку данных
с сервера на клиент

Классическое решение

Минусы подхода
• На малейший сдвиг нужно генерировать
новый запрос
• Многократная загрузка одних и тех же
данных
• Запросы всегда разные, непонятно, как
кешировать

Грузим данные потайлово

Видимая область карты
Тайлы в видимой области

Загружаем данные потайлово
• Данные загружаются всегда по одним и тем же
областям – легче организовать кеширование
• Запоминаем, какие тайлы подгружены, а
какие нет
• Небольшой сдвиг карты не вызывает
дозагрузку

RemoteObjectManager,
LoadingObjectManager
• Следят за видимой областью карты
• Следят, какие данные загружены, а какие еще нет
• Отправляют потайловые запросы за данными на
сервер
clck.ru/9Lp2J
clck.ru/9Lp2S

LoadingObjectManager
Загружает метки и кластеризует на
клиенте
RemoteObjectManager
Отвечает за загрузку и отображение
результатов серверной кластеризации

Режимы запросов за данными

Как организовать серверную
часть?

Генерация статических файлов

Генерация статических файлов
• Не требует сервера, отвечающего на запросы клиента
• Файлы могут занять очень много дискового
пространства
• Нужен скрипт, генерирующий эти файлы с некоторой
периодичностью
• Очень примитивное решение, подойдет для
небольших демо-проектов

Пространственные базы данных
• MySQL – SPATIAL
• PostgreSQL – PostGIS
• Oracle
• MongoDB
• …

Поговорим про серверную
кластеризацию точек

Кластеризация на клиенте
Сервер Клиент
Формирование
списка точек
Передача на
клиент
Кластеризация
Отображение
результата

Кластеризация на сервере
Сервер Клиент
Формирование
списка точек
Передача на
клиент

Серверная кластеризация. v1
БД Кластеризация
Отправка на
клиент

SELECT Id, long, lat,
FROM bigTable
WHERE latLon in bounds
1. Получаем данные для тайла из базы
2. Кластеризуем любым алгоритмом
3. Отправляем ответ на клиент

Можно выбрать любой
алгоритм кластеризации
Чем красивее алгоритм,
тем дольше он работает
Нужно хорошо
организовать
кеширование ответа

Grid-кластеризация

БД
клиент
Данные, сгруппированные
по grid-кластерам

SELECT MIN(id) AS minId, COUNT(id) AS count, AVG(long)
AS long, AVG(lat) AS lat,
FLOOR( long/gridFactor) * gridFactor as gridX,
FLOOR( lat/gridFactor) * gridFactor AS gridY
FROM bigTable
WHERE latLon in bounds
GROUP BY gridX,gridY
Вместе с выборкой объектов сразу объединяем объекты в grid-кластеры

Не надо писать
дополнительной логики
по кластеризации
Grid-кластеризация не
самая красивая
Быстро работает Ваша база данных вечно
считает, вы не
используете индексы

Quadkey для
grid-кластеризации

«Quadkey»
tileX = 3 = 0112
tileY = 5 = 1012
quadkey = 1001112 = 2134 = “213”
Используем битовые маски для выборки объектов в тайле
zoom = 1, mask = 110000
zoom = 2, mask = 111100
…

БД
клиент
Данные, сгруппированные
по grid-кластерам
+ quadkey для каждой
точки

SELECT MIN(id) AS minId, COUNT(id) AS count, AVG(long) AS long, AVG(lat) AS lat
FROM wiki
WHERE QuadCode between $Q1 and $Q2.
GROUP BY (QuadCode & $free)
Где:
free - маска «вариативности» хвоста.
free = 0xFFFFFFFF ^ (($Q2^$Q1)>>(2*gridFactor));
Q1,Q2 - диапазоны поиска QuadKey
Пример:
QuadCode: 320132321(base4), 9 знаков из 16(uint32)
Q1 : 320132321|0000000
Q2 : 320132321|3333333
free:333333333|3330000 (+3 зума, кластер 32х32)

Очень быстро Grid-кластеризация не
самая красивая
Нужно заранее
насчитать Quad-коды

Поговорим про кеширование и
версионирование данных

С кешированием все просто
• Поскольку запросы всегда потайловые, кешируем
ответ сервера для тайла на определенном зуме
• Пишите данные в файлы, используйте Memcached,
Redis и тд
• Если запрос поступает для большой тайловой
области, разбиваем его на отдельные тайлы и
собираем ответ из кеша потайлово

Опасный момент – обновление
данных

Опасный момент – обновление
данных
Загружены данные
старой версии
Сюда могут
подгрузиться данные
уже новой версии

Закладываем версионирование в
архитектуру
• Передаем на клиент версию данных
• Клиент всегда отправляет запросы с указанием версии
данных
• Храним несколько последних версий на сервере
• Системы кеширования тоже завязываем на версию
• Если нужно, продумываем автообновление версии на
клиенте

Полезные ссылки
• Работа с большим количеством объектов –
clck.ru/9Lp2e
• Если есть вопросы, пишите в клуб –
clubs.ya.ru/mapsapi/

Спасибо за внимание!
Марина Степанова,
руководитель группы разработки API
Яндекс.Карт
mstepanova@yandex-team.ru

ObjectManager, или как работать с большим количеством объектов на карте, Марина Степанова (Яндекс)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ObjectManager, или как работать с большим количеством объектов на карте, Марина Степанова (Яндекс)

Similar to ObjectManager, или как работать с большим количеством объектов на карте, Марина Степанова (Яндекс) (20)

More from Ontico

More from Ontico (20)

ObjectManager, или как работать с большим количеством объектов на карте, Марина Степанова (Яндекс)