0001376: Новый тип кэша на основе SQLite3 (в формате MBtiles и не в формате MBtiles)

Notes
(0007776) zed (manager) 07-07-2012 20:15	А конкретнее, в каком виде нужна поддержка: экспорт или как кэш? Если как кэш, то какой принцип сортировки или в один файл всё паковать?

(0007777) Mixailos (reporter) 07-07-2012 20:20	Первоочередно кэш, однако экспорт бы тоже не помешал. В один файл, это SQLite БД.

(0007778) zed (manager) 07-07-2012 20:28	Я понимаю, что это БД. Но вы представляете, как поведёт себя SQLite при миллионах тайлов внутри? Мне кажется, что он не выдержит такой нагрузки. Где-нибудь есть информация по нагрузочным тестам?

(0007779) Mixailos (reporter) 08-07-2012 07:40	>Я понимаю, что это БД. Но вы представляете, как поведёт себя SQLite при миллионах тайлов внутри? Мне кажется, что он не выдержит такой нагрузки. >Где-нибудь есть информация по нагрузочным тестам? Например, Mapbox и Foursquare хранят свои тайлы в MBtiles. Вероятно, потянет.

(0007781) zed (manager) 08-07-2012 18:57	>Mapbox и Foursquare Насколько я понял из непродолжительного гугления, это программы для телефонов. А там, знаете ли, совсем другие масштабы и нагрузки. И кэш там максимум на пару гигабайт. Сомнения скорее в том, потянет ли SQLite кэш размером порядка 100Гб и более, а не 5-10Гб. Лично я бы сильно опасался за кэш в сотню гиг одним файлом в SQLite.

(0007783) zed (manager) 08-07-2012 19:12	>Первоочередно кэш, однако экспорт бы тоже не помешал. Значит этот тикет про кэш, а про экспорт заводите новый (если вам нужен экспорт).

(0007784) Mixailos (reporter) 08-07-2012 19:26 edited on: 08-07-2012 19:35	>Насколько я понял из непродолжительного гугления, это программы для телефонов. Они юзают MBtiles на серверной стороне. Конечно, не исключено, что там крутится несколько MBtiles. >Значит этот тикет про кэш, а про экспорт заводите новый (если вам нужен экспорт). 0001379

(0007788) ELITE (reporter) 09-07-2012 05:11	поддерживаю - давно пора кеш в базу загнать если на сотовом он держит 5 гигов - то на стационарнке спокойно 100 должен выдержать и ЗАЧЕМ 1 файл отдельный файл для каждой карты и каждого масштаба пусть будет 2-3 десятка файлов БД и нагрузка будет меньше и в случае переноса части кеша (если надо только определенные карты и масштабы проще

(0007789) vasketsov (manager) 09-07-2012 07:23	>если на сотовом он держит 5 гигов - то на стационарнке спокойно 100 должен выдержать Чем обосновано?

(0007792) vdemidov (manager) 10-07-2012 05:40	Кстати, а в SQLite есть способы борьбы с ограничениями Fat32 на размер файла? Или 2 гига и все?

(0008639) guf (reporter) 29-08-2012 22:04	Есть проект SatMap. Он как раз в sqlite хранит кеш. При желании можно перегнать туда для тестов кеш из тайлов и посмотреть нагрузку. Кроме озвученый выше вопросов с целесообразностью хранения всего в 1 файле (в satmap можно до 100 файлов подключать, но качать только в первый по списку будет) и, например, сложностью с FAT32 у меня возник еще такой вопрос: а зачем, собственно, второй встроеный базовод, если есть беркли в котормо нет озвученых выше проблем? Если уж так хочется еще одну базу, то есть клиент-серверные базы данных, которые работают уже с другими принципами и другими нагрузками.

(0008642) vdemidov (manager) 30-08-2012 07:13	Больше кэшей хороших и разных. А движок SQLite и так в САС.Планете есть.

(0009874) Niki (reporter) 09-11-2012 13:42 edited on: 09-11-2012 13:59	http://old.n8xx.com/uploads.php?file=sas2mm.zip внутри исходники http://code.google.com/p/tilers-tools/wiki/QuickStart смотреть в сторону tiles_convert.py обсуждение обоих программ - http://n8xx.com/topic3128-sasplanet-gis.html

(0010257) vasketsov (manager) 30-12-2012 10:48	>зачем, собственно, второй встроеный базовод, если есть беркли в котормо нет озвученых выше проблем? В беркли нет автоматического восстановления после сбоев. В SQLite есть. Кроме того, кэш беркли неверсионный. Кэш SQLite если и делать - разумеется сразу полноценно версионным. >есть клиент-серверные базы данных Есть. Но считается что In-Memory работает быстрее, нет связи по сети, нет проверки прав доступа, и т.п. Хотя у меня например Informix выдаёт по сети тайлы так быстро (по прогруженному кэшу после перезапуска саса), что не всегда даже серенькие квадратики по краю экрана успевают проступать при таскании карты. То есть скорость работы - если и аргумент, то не настолько критичный, как может показаться. Основной аргумент - отсутствие небходимости настройки. Резюме: прежде всего SQLite выгоден отсутствием необходимости настройки СУБД, но всё же при наличии механизма восстановления после сбоев. Если есть какой-то используемый формат (структура таблиц), который можно использовать для кэша СРАЗУ, и исключить конвертирование и экспорт - возможно даже имеет смысл делать сразу в этом формате (если он нас всех устроит), и не брать структуру таблиц (модель данных), которую я использовал для взрослых СУБД, или которую использовал zed для беркли.

(0010258) vasketsov (manager) 30-12-2012 10:57	Но скажем так, если там возможно только как по ссылке: >> Маперавская база состоит из одной таблицы: CREATE TABLE maps(zoom integer, tilex integer, tiley integer, pixbuf blob, primary key (zoom, tilex tiley)) >> то для кэша саса не прокатит, надо как минимум дату, версию и размер (а лучше ещё и contenttype иметь), а как оно отнесётся к дополнительным полям перед BLOB-ом - большой вопрос.

(0010259) vdemidov (manager) 30-12-2012 11:21	Версия не обязательна, размер тоже. Вот терять дату будет обидно, но тоже не смертельно, а контент тайп вообще не нужен. Пусть будет задан для всего хранилища.

(0010263) zed (manager) 30-12-2012 17:28	>В беркли нет автоматического восстановления после сбоев. В определённой степени есть. Окружение (env) всегда создаётся с флагом DB_RECOVER и если с логами всё в порядке, оно должно восстановить БД до валидного состояния. >кэш беркли неверсионный Просто мне эта версионность не нужна, вот и нету её в Беркли. Но это не значит, что там это технически невозможно реализовать. Можно, и по-моему достаточно просто разрешить запись нескольких value для одного key (включается флагом при открытии/создании БД) и реализовать соответствующую логику в САС. А вот как насчёт доступа к БД SQLite из нескольких процессов одновременно? По-моему там с этим не очень гладко.

(0010269) vasketsov (manager) 30-12-2012 19:34	>оно должно восстановить БД А чё Parasite мается постоянно, по 2-3 дня базы восстанавливает? зы. Я нисколько не сарказмирую, мне и правда интересно, если у SQLite такое же восстановление после сбоев - он мне совершенно никуда не упирается при наличии беркли, так как не имеет плюсов. Некоторые вещи типа народной яндекс-карты или панорамио или викигибрида, которые в принципе долго не живут и постоянно меняются, при этом быстро выкачиваются, вполне не больно и потерять в случае падения даже при маникальной тяге к сохранению кэша. >мне эта версионность не нужна Да оно как бы понятно, что это вопрос реализации. Просто если я и буду делать кэш SQLite - я его буду делать версионным. Возможно неверсионный получится как частный случай, но городить изначально неверсионный лично мне резона нет. Итоговая цель - переносить копированием кэш на мобильные устройства, возможно когда автор андроидосаса своё поделие допилит, у него и дойдут руки до тайлов в БД. Взрослые клиент-серверные СУБД на андроиде пока что экзотика, хотя такие уже существуют. В общем цель - миграция кэша. НО версионность - не та плюшка, которой я готов пожертвовать ради копирования кэша во всякие RMaps-ы минуя процедуру экспорта. Лично я версионностью снимков пользуюсь. >как насчёт доступа к БД SQLite из нескольких процессов одновременно? По ссылке на хабре вроде бы пишут, что работает из нескольких процессов. Я SQLite даже не нюхал, чтобы это подтвердить или опровергнуть, мне достаточно что он доступен через SQL, значит я понимаю как с ним работать. Для саса будет достаточно скорости даже в самом параноидальном ультранадёжном режиме, можно даже всё тупо засинхронизировать.

(0010479) vasketsov (manager) 31-01-2013 13:27 edited on: 31-01-2013 13:43	>Если как кэш, то какой принцип сортировки или в один файл всё паковать? Уже определились с этим вопросом? Придумали как разделять все тайлы на базы? >В один файл, это SQLite БД Есть вполне обоснованные опасения, что SQLite слишком ограничен, чтобы это "взлетело" даже на одном картосервисе для всего мира по 14 зум. В одной базе возможен всего лишь миллиард страниц. зы. Чем больше читаю спеку https://github.com/mapbox/mbtiles-spec/blob/master/1.1/spec.md тем больше понятно, что стандарт для хранилища мертворожденный, только jpeg или png уже напрягает, обязательную запись bounds в метаданных придётся постоянно актуализировать,... короче говоря слишком всё ограничено, чтобы подписываться на этот стандарт, вот для экспорта самое оно )))

(0010931) vasketsov (manager) 26-03-2013 17:29	Итак посчитаем: 1. Размер страницы SQLite от 512 байт до 64k. 2. В одной базе может быть не более 1 073 741 823 страниц. 3. Если средний тайл даже 30k, то значит 1 такой средний тайл занимает от 1 до 64 страниц. 4. Значит максимальное число таких тайлов в базе (крайности) или 1 073 741 823 тайлов, или 16 777 216 тайлов. 5. Если предусмотреть 16 версий в среднем на тайл - получается лимон тайлов в одной базе. 6. Даже если без версий и тайлы меньше, всё равно лимон тайлов в базе - это мягко говоря немало, для тайлов размером 20k это будет файл в 20 гигов )) 7. Итого максимум 1048576 = 10241024 тайлов (в смысле пар xy) в одной БД. На зуме 1 - 11 = 1 тайл. На зуме 2 - 22 = 4 тайла. На зуме n - 2^(n-1)2^(n-1) = 4^(n-1) тайлов. На зуме 9 - 256256 тайлов = 65536 тайлов. Итого все зумы от 1 до 9 включительно можно сложить в одну базу. Зум 10 сам по себе целиком и один можно сложить одну базу (10241024 = 1048576 тайлов). Но что-то это очково, файл базы получается совсем гигантским. Так что пожалуй поделимся на 4 (в смысле числа записей). Так что получается примерно так: а) зумы с 1 по 8 - все зумы в сумме в одной базе; б) зум 9 - один в одной базе (65536 тайлов); в) зум 10 - в 4 базах (каждая по 65536 тайлов, деление типа qrst, то есть по квадратам); г) зум 11 - в 44 = 16 базах - в одной папке z11; д) зум 12 - в 164 = 64 базах - в одной папке z12; е) зум 13 - в 256 базах - в одной папке z13; ё) зум 14 - в 1024 базах - и это максимум в одной папке z14; Начиная с зума 15 надо ещё более активно делиться: ж) зум 15 - в 4 подпапках (по 1024 базы) внутри z15 - в 10244 базах; з) зум 16 - в 16 подпапках (по 1024 базы) внутри z16 - в 102416 базах; и) зум 17 - в 256 подпапках (по 1024 базы) внутри z17 - в 1024256 базах; й) зум 18 - в 1024 подпапках (по 1024 базы) внутри z18 - в 10241024 базах; Начиная с зума 19 используем ещё один уровень (соответственно покрываем этим зумы 19-22). Экстраполируя за 22, аналогично для самый отъявленных извращенцев добавляем по ещё одному уровню подпапок на каждые 4 зума. А теперь надо взять бутылку и разобраться, как это закодировать, чтобы было максимально быстро. зы. Вариант типа TTileFileNameBerkeleyDB.GetTileFileName Не нравятся тем, что соседние x и y будут в разных базах. А если сделать как написано - для отображения экрана надо будет слазить не более чем в 4 базы, и то если клинически не повезёт, и в рамки экрана попадёт стык квадратов, по которым тайлы делятся, а чаще всего потребуется доступ к одной базе. Ну и карту заполнения можно будет строить большими прямоугольниками, типа как я сейчас для СУБД её строю.

(0010932) zed (manager) 26-03-2013 17:39	Т.е. ты в один файл суёшь 256256 тайлов, так же, как и в Беркли (не считая z1-z8), но сортировку хочешь придумать динамическую, в зависимости от зума? А нафига так извращаться? Вложенных папок и так получается по минимуму. Делай как Беркли - будет всё единообразно и понятно. >Вариант типа TTileFileNameBerkeleyDB.GetTileFileName Не нравятся тем, что соседние x и y будут в разных базах. C какой такой стати? Там же те же квадраты 256256 тайлов и всё лежит рядышком. А в соседней оно папке или в той же самой - не суть.

(0010933) vasketsov (manager) 26-03-2013 18:53	>C какой такой стати? А фиг его знает почему я так подумал. Вернее догадываюсь, что слишком рано начал разбираться )). Был неправ. На самом деле даже когда соседние xy в одной базе, если их не приводить, а сохранять как есть в виде int - они и будут далеко друг от друга на разных страницах, и IO будет больше, чем если например оставить только smallint или вообще byte (покуда 65536 это 256*256). Но поскольку в SQLite поля почти не типизированы (есть ровно одно исключение из этого правила - это одиночный INTEGER PRIMARY KEY), не факт что это поможет сэкономить, пробовать надо будет. А то может вообще придётся упаковываться как раз в этот самый INTEGER PRIMARY KEY (и тогда xy займут 2 байта, а ещё 2 байта уйдут под опциальную версию и т.п.). В общем тут отсутствие возможности строгой типизации полей в PRIMARY KEY играет негативную роль в части объёма для хранения полей в ключе (так как для каждого поля хранится его тип для каждой записи). >Делай как Беркли - будет всё единообразно и понятно Ну давай попробуем для начала как BDB. Если в базе будет только один зум - будет даже проще. А вообще там ещё на каждую базу будет 2 файла лога (по умолчанию режим WAL), то есть база - это 3 файла. Делать общий лог не хочется, так как по умолчанию attach можно сделать не более чем 10 базам, а вообще теоретический предел это 62 базы, так что придётся с кажой базой работать независимо. Так что число баз в конечной папке ещё утроится.

(0010934) zed (manager) 26-03-2013 19:02	>На самом деле даже когда соседние xy в одной базе, если их не приводить Ну, в Беркли они как раз таки упаковываются. Правда не знаю, как там поступает БД - оптимизирует только хранение ключей или же и данные тоже сортирует.

(0010944) vasketsov (manager) 30-03-2013 23:09	Вощем погонял googlesat с 1-го по 9-й зумы (покуда один зум в одну базу падает). Экономия на упаковке xy ровным счётом никакая. Даже запись contenttype словами - вообще ни разу погоды не делает, а сначала хотел цифрами загонять или NULL для основного типа. Возможно если сделать меньше размер страницы - оно и будет важно. Короче говоря решил упаковываться и считать байты только если что-то не устроит по размеру или скорости. А пока не упаковываемся и байты не считаем. Пока лично меня всё устраивает: теоретически это должно быть второе по скорости работы локальное хранилище после беркли. Вариант неверсионного хранилища в SQLite будет как опция.

(0010961) vasketsov (manager) 02-04-2013 10:28	Итак, покуда готово всё, кроме интерфейса для менеджера кэша, и можно уже начинать играться, опишу некоторые нетривиальные моменты. 1. Тип кэша в zmp надо писать как 71. 2. Внутри папки с кэшем структура похожа на беркли, кроме папки env. 3. Внутри папки с кэшем (там где будут папки z1..z23) можно создать 3 необязательных файлика для модификации поведения SQLite. О них чуть позже. По умолчанию работает и без них. Там же в случае ошибок будет копиться лог в файле sqlite.log. 4. Хранилище версионное. Неверсионность реализуется как опция. Проще всего её включить через один из файликов из предыдущего пункта. 5. Доступ из нескольких сасов в один кэш возможен. Доступ из нескольких zmp из одного саса в один кэш также возможен. Доступ к логу также возможен из нескольких сасов. Короче, ограничений в части конкурентного доступа пока никаких нет. 6. В случае падения саса или sqlite по идее базы должны подниматься автоматически, никакой особенной работы для их восстановления не предполагается. 7. Если по результатам игр обнаружится, что структуру БД надо менять, то со старыми данными, накопленными по результатам игр, обновлённая версия работать не будет. Та что покуда пункт не закрыт (даже если разработка затянется и будет казаться, что ничего уже не будет меняться) - не мигрируйте в SQLite.

(0010962) vasketsov (manager) 02-04-2013 10:46	Теперь про необязательные файлики. Все они исполняются как команды SQL, причём построчно (каждая строка исполняется как отдельная команда). Если соответствующий файл существует и пустой - ничего не будет выполнено. Если файла нет - будет выполнен код по умолчанию. 1. Файл s.sql. В нём хранится код инициализации сессии. Он выполняется всегда при открытии или создании новой БД самым первым. По умолчанию при отсутствии файла выполняются следующие команды: PRAGMA cache_size=100000 PRAGMA main.journal_mode=WAL PRAGMA synchronous=NORMAL Один из возможных примеров настройки - это включение размера страницы для работы с БД размером 512 байт для пущей компактности хранилища. Оно конечно влияет на скорость, но на обычной работе не заметно, заметно возможно будет при миграции в момент переноса кэша, но покуда интерфейс к менеджеру кэша не написан - однозначно утверждать об этом нельзя. Чтобы включить размер страницы 512 байт, надо чтобы файл s.sql был например таким: PRAGMA page_size=512 PRAGMA cache_size=100000 PRAGMA main.journal_mode=WAL PRAGMA synchronous=NORMAL 2. Файл t.sql. В нём хранится код создания таблицы с тайлами. Он исполняется, только если таблицы с тайлами ещё нет. Обращаю внимание, что этот файл также исполняется построчно. По умолчанию если нет файла, таблица создаётся так: CREATE TABLE IF NOT EXISTS t ( x INTEGER NOT NULL, y INTEGER NOT NULL, v INTEGER DEFAULT 0 NOT NULL, c TEXT, s INTEGER DEFAULT 0 NOT NULL, d INTEGER NOT NULL, b BLOB, constraint PK_TB primary key (x,y,v)) Если из этого кода удалить поле v и сложить его в файл t.sql в ОДНУ строку - создаваемое хранилище будет неверсионным. Также допускается отсутствие поля c (contenttype). Все остальные поля обязаны присутствовать. Поле d - это дата в виде unix-секунд. Остальное вроде понятно. 3. Файл e.sql. Выполняется после возможного выполнения файла t.sql всегда, как самый последний из трёх, для того чтобы можно было выполнить что-нибудь над уже созданной или существующей таблицей. По умолчанию при его отсутствии ничего не выполняется.

(0010963) zed (manager) 02-04-2013 11:55	> 5. Доступ из нескольких сасов в один кэш возможен. Но перманентно сыпятся ошибки: "database is locked ( error code: 5)". По крайней мере, при активной загрузке одного и того же региона двумя сасами в 2-4 потока. К слову, такого же типа ошибка возникает и в версионном Беркли, который я сейчас ковыряю. Только там это называется DEADLOCK. И видимо, тут уже ничего не попишешь. И похоже, что у тебя эти исключения наружу не вылазят, а сбрасываются в лог (он для релизной версии тоже будет работать или только под дебагом, как в Беркли?).

(0010964) vasketsov (manager) 02-04-2013 13:15	>database is locked Это что-то недокручено просто в настройках. Например возможно спасёт PRAGMA synchronous=FULL http://www.sqlite.org/pragma.html А возможно от FULL такие тормоза будут, что придётся просто повторять руками команду SQL при такой ошибке. >исключения наружу не вылазят Для релизной не планировалось, но можно и включить. Также что они не вылазят - тоже не планировалось, так получилось ))

(0010971) zed (manager) 03-04-2013 17:24	Наблюдаются проблемы с отображением тайлов. Т.е. некоторые тайлы вроде как в кэше и есть, но на экране их нет. После перезапуска SAS обычно появляются. Наблюдается на участках, которые только что были загружены. При запуске в режиме "Только из кэша" проблем нету.

(0010972) zed (manager) 03-04-2013 17:42	>Это что-то недокручено просто в настройках. Например возможно спасёт PRAGMA synchronous=FULL Не спасает. Полный текст ошибки: "2013-04-03 20:35:10.363 r database is locked ( error code: 5)". r - это значит операция чтения спотыкается? >А возможно от FULL такие тормоза будут Судя по счётчикам, скорость записи падает раза в 3 и становится примерно равной скорости Беркли (в районе 0,02-0,04 сек. против ~0,005 при synchronous=NORMAL).

(0010974) vasketsov (manager) 03-04-2013 19:28	>вроде как в кэше и есть, но на экране их нет Я сейчас полечил одну странную багу, из-за которой при построении карты заполнения при указании длинной версии в виде 16-ричного числа SQLite лажался на конвертации, если для конкретного тайла есть цифровая версия или есть тайл без версии. Пришлось через CAST сравнение писать, хотя в соответствии с мануалами SQLite обязан отрабатывать без ошибки и без CAST-а. Для этого же тайла при обычном чтении по одному ошибки не было (да и не всегда для карты заполнения стреляло, завесело от диапазона between, в общем ерунда какая-то, не поддающаяся логике). Возможно это как-то связано, что SQLite не всегда корректно идентифицирует строковую версию, если она в виде длинного числа представлена. Если вдруг налетишь на такое ещё раз - сразу же попробуй по ПКМ посмотреть какие версии есть у этого тайла. Хотя конечно может всё куда проще, например из-за memcache )) >r - это значит операция чтения спотыкается? Нет. Это как раз вставка (ну или обновление). Вот коды операций для лога: 'i' - это инициализация 'd' - это удаление 's' - это чтение тайла 'r' - это вставка или обновление тайла 'v' - это получение списка версий 'm' - это построение карты заполнения >database is locked Пока не придумал, чего с этим делать.

(0010975) vasketsov (manager) 03-04-2013 19:33	Хм. Есть вариант попробовать другую крайность: PRAGMA synchronous = OFF 2ALL: И на всякий случай напоминаю, что режим WAL можно использовать только для локальных баз SQLite: WAL does not work over a network filesystem

(0010976) zed (manager) 03-04-2013 19:34	>Если вдруг налетишь на такое ещё раз Воспроизводимость 100%. На карте гугл сат, версия там числовая (126). В процессе тестирования версию вообще не трогаю. Пока что. >Вот коды операций для лога: А почему бы словами сразу в лог не написать, дабы без вопросов было понятно? >Пока не придумал, чего с этим делать. Ну, оно в общем и не критично. Просто есть такой момент. А вот баг с неотображением тайлов уже серьёзный.

(0010977) vasketsov (manager) 03-04-2013 19:44	http://www.sqlite.org/cvstrac/wiki?p=MultiThreading By "threadsafe" we mean that you can use different SQLite database connections in different threads at the same time. It has never been safe to use the same database connection simultaneously in multiple threads. If you use the ¤sqlite3_prepare() API to create prepared statements, each prepared statement is considered to be a part of the database connection from which it was derived. So you cannot run two prepared statements originating from the same database connection in different threads at the same time. Походу всё чуть сложнее, чем хотелось бы. Судя по всему "типа MARS" (Multiple Active ResultSet) не фурычит. Только на взрослых СУБД под MARS понимается SELECT (чтобы был ResultSet), а тут вообще любой запрос ((

(0010978) vasketsov (manager) 03-04-2013 19:49	>Воспроизводимость 100% А чё делаешь? Просто в режиме кэш+инет по карте шаришься туда-сюда и назад для проверки? и вдруг видишь что только что загруженный тайл вдруг отсутствует и отображается размазанным как будто с верхних уровней? или что-то более интеллектуальное? >почему бы словами сразу в лог не написать это чтобы табуляциями смысловая часть была выровнена. хотя если придумается как словами чтобы ровно - изменю. это очевидно не связано с размером лога )) >оно в общем и не критично это смотря как ошибку словить. если это будет в закачке экранной области и вылетит рабочий поток - будет неприятно.

(0010980) zed (manager) 03-04-2013 20:03	>Хм. Есть вариант попробовать другую крайность: PRAGMA synchronous = OFF Хм, да - ошибки пока не попадаются. По крайней мере в логе. Под дебагером не пробовал. >А чё делаешь? Удалил кэш, запустил SAS, ничего не трогаю, он згрузил один экран (40 тайлов). Всё ок, все тайлы нарисовались. Перезапускаю SAS - дырки. Включаю режим Кэш, перезапускаю - Ок. Включаю режим Инет + Кэщ, перезапускаю - дыри %) Дырки появляются рандомно от одного перезапуска к другому. Из инета при этом ничего не загружается. >это чтобы табуляциями смысловая часть была выровнена Ну, буковку можешь оставить, а потом словами дописать расшифровку + текст ошибки

(0010981) zed (manager) 03-04-2013 20:04 edited on: 03-04-2013 20:08	Да, в zmp подкручено MaxConnectToServerCount=12, но и с 1 всё аналогично, кроме разве что рандомность появления дырок пропадает/уменьшается - за несколько перезапусков появились на одном и том же месте. Ручная перезагрузка тайлов не помогает.

(0010983) vasketsov (manager) 03-04-2013 20:16	>перезапускаю - дыри О. Благодарю. Теперь появилась идея, как такое возможно.

(0010989) vasketsov (manager) 04-04-2013 10:16	Похоже что-то с memcache напуталось - после отключения все тайлы показываются. Временно его отключил.

(0011002) zed (manager) 04-04-2013 15:51	Появилась идея по поводу приоритетов версий тайлов при отображении, и ручным управлением этими самыми приоритетами. К примеру, у нас есть снимки версий 120 и 121. Мы хотим, чтобы для определённого региона, снимок из 120-й версии показывался поверх 121-й (но и 121-й удалять не хотим). Т.е. естественно, что если мы выбрали показывать только 121-ю версию, она нам и покажется без всяких приоритетов, но вот в режиме "любой доступный", у нас он всплывёт на верх. Чтобы такое происходило, обычное сравнение версий уже не прокатит и нужен какой-то дополнительный параметр, на которой сможет влиять пользователь (через операции с выделенной областью, к примеру). Таким образом можно будет комбинировать видимость и управлять перекрываемостью снимков разных версий.

(0011003) vasketsov (manager) 04-04-2013 17:31	Что-то я пока не очень понимаю реальное применение такой фичи. Приоритет тайлов потребует фактически для всех талов добавить одно поле, и ради нескольких десятков тайлов городить это вместо переключения версии мне кажется негуманным. Да и в случае снимков, стыковка тайлов будет с разными смещениями, вряд ли красиво получится. Как вариант - придумать алгоритм ссылки на другую версию, и нагенерить таким образом версию "зе_бест" ссылками на разные версии (например если размер<0 или не число - значит ссылка). Для сравнения: сейчас в СУБД зарезервировано поведение, что если размер<0 - это ссылка на реестр часто используемых тайлов (но это пока не сделано, хотя запросы, настройки и таблички к этому готовы). Хотя я в принципе сомнительно отношусь к таким "сборным-солянкам", ибо переключить версию проблем же никаких нет, и путаницы не будет.

(0011004) zed (manager) 04-04-2013 17:48	>ради нескольких десятков тайлов Снимок покрывающий небольшой город на 19-м зуме, будет не несколько десятков тайлов, а чутка по-более. И то, что там ещё пара байт будет задействована, так разве ж это принципиально? >ибо переключить версию проблем же никаких нет, и путаницы не будет Надоест постоянно переключаться ради одного снимка - туда, а ради другого - сюда. Ещё и помнить надо, в какой версии лежит нужный снимок, для данного региона.

(0011005) vasketsov (manager) 04-04-2013 18:17	>небольшой город на 19-м зуме я понял что ты только для тех мест, где надо руками управлять, хочешь приоритет править. если снимок на весь город - его нао просто включить и всё. >то, что там ещё пара байт будет задействована, так разве ж это принципиально? Для хранилищ NoSQL они же "ключ-значение" куда относится и беркли - думаю что не принципиально. Для СУБД (я сейчас не про SQLite) с кластерным первичным ключём (x,y,v), или с некластерным пк но покрывающим его кластерным индексом (x,y,v,size) - принципиально. Добавление ещё одного левого поля в ORDER BY (причём перед v!) практически гарантировано на больши объёмах будет приводить к созданию worktable и падению производительности на SELECT-ах. Это даже без тестов можно предположить. Что будет в SQLite я сказать не могу ввиду отсутствия опыта работы с ним.

(0011026) zed (manager) 05-04-2013 18:05	>Похоже что-то с memcache напуталось - после отключения все тайлы показываются. Временно его отключил. 1. Мемкэш неверсионный 2. При получении из него, нужно проверять на интерфейс ITileInfoWithData, если ожидается тайл с данными. Ну или доработать мемкэш, чтобы он сам возвращал нужный интерфейс, чтобы в каждом хранилище не плодить тучу проверок. Это всё можно сказать баги мемкэша.

(0011049) vasketsov (manager) 08-04-2013 18:40	По результатам тестов отчёт о проделанной работе: 1. Размер страницы при желании сэкономить место лучше делать не 512, а 1024. Разница небольшая (для dg оказалось примерно 5 мегов на каждые 10 гигов кэша), а средняя скорость чтения на четверть выше. 2. Если предполагается перенос кэша между разными платформами, рекомендую всегда указывать размер страницы, так как на разных платформах он по умолчанию разный. Пусть даже это будет 4096 - но чтобы был. 3. При миграции через менеждер кэша настройки (файлики sql) в целевой папке надо создавать заранее (если нужны отличия от значений по умолчанию). При этом можно указать PRAGMA synchronous=OFF, и если не было ошибок при переносе кэша - после переноса закрыть сас и заменить OFF на NORMAL. Будет примерно раз в 5 быстрее переноситься, но если вдруг навернётся электропитание - может быть неприятно. Ещё быстрее было бы, если бы все тайлы в БД залетали в одной транзакции, но это мало того что пока не реализуемо, так ещё и опасно в случае переноса (а не копирования) кэша. 4. При необходимости одновременной работы по сети SQLite никак не заменит СУБД. Несмотря на то что некоторые тут метки в SQLite по сети гоняют, тайлохранилище всё же более серьёзная вещь. 5. Формат БД для SQLite править уже не буду, вроде всё пашет и не валится. 6. Резервное копирование (создание бэкапов) проще всего осуществлять простым батником, запускаемым из папки с кэшем, который скопирует всю папку вместе с собой рекурсивно например на сетевое хранилище. Дабы все базки позакрывались - лучше это делать при выключенном сасе. 7. Из доработок осталось восстановить memcache + подумать на тему пула statement-ов (есть мысть, что на этом можно неплохо сэкономить). Больше ничего серьёзного не осталось.

(0011058) Mixailos (reporter) 10-04-2013 18:39	Что-то полученные файлы не хотят открываться референсной mbutil.

(0011059) vasketsov (manager) 10-04-2013 18:47	>референсной mbutil Что такое mbutil?

(0011060) Mixailos (reporter) 10-04-2013 19:56	Программа для работы с MBtiles на python от Mapbox https://github.com/mapbox/mbutil

(0011061) vasketsov (manager) 10-04-2013 20:12	Понятно. Кэш этот не в формате MBtiles (и об этом в теме написано, чтобы повысить внимательность - поправил заголовок). Формат MBtiles слишком ограничен и неудобен, чтобы на его основе делать рабочий кэш саса. В MBtiles будет только экспорт.

(0011063) vasketsov (manager) 11-04-2013 05:44	Хотя вот сегодня подумалось, что если сделать для MBtiles разделение по версиям (VersionInCache=1 и без деления по зумам), то он и вправду может выдержать например обновление яндекса, гугла или бинга, и уж тем более например снимок роскосмоса или отдельные снимки dg. Пожалуй надо будет попробовать. При всех проблемах такого решения, плюсы в части миграции тоже есть. А пока настоящим сообщаю о завершении работ по типу кэша SQLite. Желающие могут начинать играться, мигрировать, писать о багах и т.п.

(0011073) vasketsov (manager) 13-04-2013 21:40	Кэш в формате MBtiles сделан отдельным номером 72. Не забываем включать для него VersionInCache.

(0011147) vasketsov (manager) 18-04-2013 13:59	Ух чего нашлось: http://www.sqlite.org/src4/artifact/41b08c1d31c156d3916558aad89b7e7ae8a381c5 LSM SQLite4: LSM supports a single-writer/multiple-reader MVCC based transactional concurrency model. SQL style nested sub-transactions are supported. Clients may concurrently access a single LSM database from within a single or multiple application processes. An entire LSM database is stored in a single file on disk. Data durability in the face of application or power failure. LSM may optionally use a write-ahead log file when writing to the database to ensure committed transactions are not lost if an application or power failure occurs. LSM may be configured to use external data compression and/or encryption routines to create and access compressed and/or encrypted databases.

Users who viewed this issue
User List	Anonymous (8236x), zed (2x), zloyboy79 (3x), SlavutichRED (2x), lovegrach (4x), k-dmitriy (1x), goodzon (1x), vasketsov (1x), Crursh-91 (1x), Drusja_1984 (1x), anf (1x), bk99 (1x), Tolik (1x), vdemidov (3x), Garl (1x), Institor (1x), Ivan_Zykov (4x)
Total Views	8264
Last View	21-11-2024 10:40

Issue History
Date Modified	Username	Field	Change
07-07-2012 19:56	Mixailos	New Issue
07-07-2012 20:15	zed	Note Added: 0007776
07-07-2012 20:20	Mixailos	Note Added: 0007777
07-07-2012 20:28	zed	Note Added: 0007778
08-07-2012 07:40	Mixailos	Note Added: 0007779
08-07-2012 11:48	gpsMax	Tag Attached: БД
08-07-2012 18:57	zed	Note Added: 0007781
08-07-2012 19:02	zed	Summary	Поддержка MBtiles => Новый тип кэша в формате MBtiles (на основе SQLite3)
08-07-2012 19:12	zed	Note Added: 0007783
08-07-2012 19:13	zed	Tag Attached: кэш
08-07-2012 19:26	Mixailos	Note Added: 0007784
08-07-2012 19:29	Mixailos	Note Edited: 0007784	View Revisions
08-07-2012 19:35	Mixailos	Note Edited: 0007784	View Revisions
08-07-2012 19:41	zed	Relationship added	related to 0001379
08-07-2012 19:44	zed	Severity	major => feature
09-07-2012 05:11	ELITE	Note Added: 0007788
09-07-2012 07:23	vasketsov	Note Added: 0007789
10-07-2012 05:40	vdemidov	Note Added: 0007792
09-08-2012 06:56	vdemidov	Product Version	.Nightly => 110418
28-08-2012 14:44	vdemidov	Status	new => confirmed
28-08-2012 14:46	vdemidov	Target Version	=> 1305xx
29-08-2012 22:04	guf	Note Added: 0008639
30-08-2012 07:13	vdemidov	Note Added: 0008642
09-11-2012 13:42	Niki	Note Added: 0009874
09-11-2012 13:59	Niki	Note Edited: 0009874	View Revisions
30-12-2012 10:48	vasketsov	Note Added: 0010257
30-12-2012 10:57	vasketsov	Note Added: 0010258
30-12-2012 11:21	vdemidov	Note Added: 0010259
30-12-2012 17:28	zed	Note Added: 0010263
30-12-2012 19:34	vasketsov	Note Added: 0010269
30-12-2012 20:00	vasketsov	Tag Attached: SQLite
31-01-2013 13:27	vasketsov	Note Added: 0010479
31-01-2013 13:43	vasketsov	Note Edited: 0010479	View Revisions
31-01-2013 13:43	vasketsov	Note Edited: 0010479	View Revisions
26-03-2013 14:00	vasketsov	Assigned To	=> vasketsov
26-03-2013 14:00	vasketsov	Status	confirmed => assigned
26-03-2013 17:29	vasketsov	Note Added: 0010931
26-03-2013 17:39	zed	Note Added: 0010932
26-03-2013 18:53	vasketsov	Note Added: 0010933
26-03-2013 19:02	zed	Note Added: 0010934
30-03-2013 23:09	vasketsov	Note Added: 0010944
02-04-2013 10:28	vasketsov	Note Added: 0010961
02-04-2013 10:46	vasketsov	Note Added: 0010962
02-04-2013 11:55	zed	Note Added: 0010963
02-04-2013 13:15	vasketsov	Note Added: 0010964
03-04-2013 17:24	zed	Note Added: 0010971
03-04-2013 17:42	zed	Note Added: 0010972
03-04-2013 19:28	vasketsov	Note Added: 0010974
03-04-2013 19:33	vasketsov	Note Added: 0010975
03-04-2013 19:34	zed	Note Added: 0010976
03-04-2013 19:44	vasketsov	Note Added: 0010977
03-04-2013 19:49	vasketsov	Note Added: 0010978
03-04-2013 20:03	zed	Note Added: 0010980
03-04-2013 20:04	zed	Note Added: 0010981
03-04-2013 20:08	zed	Note Edited: 0010981	View Revisions
03-04-2013 20:16	vasketsov	Note Added: 0010983
04-04-2013 10:16	vasketsov	Note Added: 0010989
04-04-2013 15:51	zed	Note Added: 0011002
04-04-2013 17:31	vasketsov	Note Added: 0011003
04-04-2013 17:48	zed	Note Added: 0011004
04-04-2013 18:17	vasketsov	Note Added: 0011005
05-04-2013 18:05	zed	Note Added: 0011026
08-04-2013 18:40	vasketsov	Note Added: 0011049
10-04-2013 18:39	Mixailos	Note Added: 0011058
10-04-2013 18:47	vasketsov	Note Added: 0011059
10-04-2013 19:56	Mixailos	Note Added: 0011060
10-04-2013 20:08	vasketsov	Summary	Новый тип кэша в формате MBtiles (на основе SQLite3) => Новый тип кэша на основе SQLite3 (не в формате MBtiles)
10-04-2013 20:12	vasketsov	Note Added: 0011061
11-04-2013 05:44	vasketsov	Note Added: 0011063
13-04-2013 21:39	vasketsov	Summary	Новый тип кэша на основе SQLite3 (не в формате MBtiles) => Новый тип кэша на основе SQLite3 (в формате MBtiles и не в формате MBtiles)
13-04-2013 21:40	vasketsov	Note Added: 0011073
18-04-2013 13:59	vasketsov	Note Added: 0011147
06-05-2013 20:42	vasketsov	Project	SAS.Планета => SACS.Планета
06-05-2013 20:43	vasketsov	Status	assigned => resolved
06-05-2013 20:43	vasketsov	Fixed in Version	=> .Nightly
06-05-2013 20:43	vasketsov	Resolution	open => fixed
07-05-2013 07:05	vdemidov	Issue cloned: 0001919
07-05-2013 07:05	vdemidov	Relationship added	related to 0001919
09-08-2013 14:59	vasketsov	Fixed in Version	.Nightly => 130803
09-08-2013 15:13	vasketsov	Status	resolved => closed
16-06-2016 07:01	zed	Relationship added	related to 0001920

SASGIS