SASGIS

Веб-картография и навигация

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0002708

SAS.Планета

[All Projects] Хотелка

public

01-05-2015 20:38

27-03-2019 07:52

Reporter

vasketsov

Assigned To

Priority

normal

Severity

minor

Reproducibility

N/A

Status

confirmed

Resolution

open

Platform

OS Version

Product Version

181221

Target Version

50xxxx

Fixed in Version

Summary

0002708: Промежуточный кэш для оптимизации записи для медленных тайлохранилищ

Description

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

Идея заключается в том, чтобы сохранить скачанный тайл в промежуточный кэш в памяти, и сливать его в хранилище по мере накопления, по событию Sync, при закрытии тайлохранилища, при смене версии и т.п. - в общем, по достаточно редким событиям (кроме разве что накопления, ибо можно просто сделать ограничение сверху на размер этого кэша, скажем 10, и сливаться он будет довольно часто).

Поскольку это всё прежде всего зависит от картосервиса (насколько он быстрый), а также от расположения и типа тайлохранилища, делать этот кэш общим на все карты неразумно, логичнее всего его иметь внутри ITileStorage.
Наверное, он должен быть технически похож на существующий кэш тайлов в памяти (в общем случае - быть версионным), но соответственно всё сохранение тайлов в хранилище должно идти через него (а уже из него по событию должен осуществляться массовый слив тайлов в нижележащее хранилище).
Для того, чтобы убедиться в способности хранилища реально сохранять тайлы, первый тайл должен пролететь успешно мимо этого кэша, как сейчас, хотя это и не обязательно.
Возможно, потребуется сделать новый метод в интерфейсе, который бы сливал этот кэш в тайлохранилище, если кэш будет не внутри ITileStorage, а например на уровне карты.
Всё это должно работать только при включении параметра в Zmp, как сейчас обстоит дело с MemCache.
Как пример, когда это будет мегаполезно: если тайлохранилище состот из нескольких файлов БД, доступ к которым (поиск, открытие, чтение) осуществляется исходя из тайловых координат (x,y,z,v). Алгоритм сливания кэша в хранилище не регламентируется, поскольку зависит от его структуры и природы, но в частности, можно итеративно открывать БД для первого тайла, сливать из кэша в БД всё что туда подходит (а при скачке по выделенной области это будет как раз оптимум), и далее повторять это, пока кэш не опустеет.
Возможно даже сделать два таких кэша, чтобы пока один сливается, второй мог заполняться снаружи новыми тайлами.

А может быть всё совсем не так, и надо просто немного изменить существующий MemCache, чтобы он заработал и за себя и за того парня, хотя существующие концептуальные проблемы заполнением и поиском внутри MemCache наводят на мысль, что поручать ему это нельзя.

Tags

No tags attached.

Attached Files

Relationships

related to

0001200

resolved

zed

Добавить кэширование тайлов на уровне тайлохранилища

Notes
(0015819) vdemidov (manager) 03-05-2015 06:50	Ну, не знаю, как по мне так это детали реализации конкретного типа тайлохранилища. Пусть оно себе запоминает как хочет, может просто сохранять в буфер, а раз в пару секунд запускать сбрасывание буферов на диск и тд.

(0015820) vasketsov (manager) 03-05-2015 08:45	>детали реализации конкретного типа тайлохранилища Ну хоть как назови. Суть-то в том, что на это поведение надо влиять. Очевидно, из zmp. Кроме того, это может быть полезным и для простого файлового хранилища, если оно на сетевой шаре. И для записи в архив. В общем, это может быть полезно в качестве базовой функциональности для всех типов тайлохранилищ, разве что кроме RAM.

Users who viewed this issue
User List	Anonymous (2290x), vdemidov (10x), zed (1x), vasketsov (1x)
Total Views	2302
Last View	21-11-2024 12:46

Issue History
Date Modified	Username	Field	Change
01-05-2015 20:38	vasketsov	New Issue
03-05-2015 06:50	vdemidov	Note Added: 0015819
03-05-2015 08:45	vasketsov	Note Added: 0015820
31-07-2015 10:18	vdemidov	Relationship added	related to 0001200
27-03-2019 07:52	vdemidov	Status	new => confirmed
27-03-2019 07:52	vdemidov	Product Version	=> 181221
27-03-2019 07:52	vdemidov	Target Version	=> 50xxxx
13-07-2019 14:30	RIXXX	Issue cloned: 0003476