0000124: Тайлохранилище в виде набора баз BerkeleyDB

Notes
(0000228) vdemidov (manager) 24-09-2010 13:57 edited on: 06-04-2011 23:41	Всем хочется, и мне в том числе. Будет одновременно с поддержкой плагинов.

(0000343) Tikh (reporter) 14-10-2010 08:00	Скажите, а когда примерно ждать поддержку плагинов?

(0000344) vdemidov (manager) 14-10-2010 08:20	Как только так и сразу

(0000395) DJ VK (manager) 05-11-2010 05:36	Пожелание. прошу учесть. Не надо делать 2-3 базы данных очень большого размера. Прошу 1. разбить базу на среднего размера файлы. в файле 16k или 64k тайлов. Чтобы разбиение было по квадратам, а размер одного файла не превышал 1-1,2 ГБ. тогда легче обмениваться. 2. Организовать возможность раздельного хранения файлов баз - создается список путей, и при работе в автомате в соответствии с очередностью последовательно они заполняются, забив один диск (например задается квота свободного места. достигнута - переход к след папке) идем на другой. а пользователь может переносить при желании файлы баз между этими путями. Когда будет мультизакачка слой за слоем автоматическое забивание дисков может и пригодиться. 3. Если квоты исчерпаны пользователь получает уведомление - некуда скачивать.

(0001578) gpsMax (manager) 06-04-2011 23:44	Насчёт медленного копирования - на форуме было подробное обсуждение данного вопроса. Лучшим обходным решением было признано создание контейнеров в TrueCrypt, но это именно временное обходное решение. Хотя, надо сказать, работает неплохо.

(0002129) Tikh (reporter) 20-04-2011 10:26	Не поделитесь ссылочкой на форум, где обсуждают True Crypt?

(0002143) gpsMax (manager) 20-04-2011 12:01	http://sasgis.org/forum/viewtopic.php?f=3&t=540 Исходная тема, 12 страниц, но оно того стоит. плюс http://sasgis.org/forum/viewtopic.php?f=2&t=24&start=30 (немного про Truecrypt) http://sasgis.org/forum/viewtopic.php?f=2&t=34 http://sasgis.org/forum/viewtopic.php?f=2&t=1092

(0002145) Papazol (reporter) 20-04-2011 16:49	Есть такая идея: сохранять кэш каждой карты в совершенно отдельную папку. Чтобы не только название папки NameInCache задавалось, но и полный путь. Это позволит, например, задать в том же TrueCrypt для каждого кэша отдельный контейнер. И обрабатывать содержимое кэша будет проще, так как файлы будут меньшего размера.

(0002148) vdemidov (manager) 20-04-2011 16:58	И кто вам мешает?

(0002207) Papazol (reporter) 21-04-2011 11:18	Отсутствие многих знаний. Как я считаю, путь ко всему кэшу программы прописывается в настройках, и он един для всех карт. Различия только в названиях папок, но лежат-то они все в одной. Не догоняю чего-то я?

(0002209) vdemidov (manager) 21-04-2011 11:32	В NameInCache вполне можно прописывать полный путь. Это первый вариант. Второй это монтирование дисков как папок.

(0002211) Papazol (reporter) 21-04-2011 11:37	Надо попробовать по первому варианту. Второй не подходит мне, так как нужно обратное: смонтировать папки, точнее, файлы, как диски.

(0002215) gpsMax (manager) 21-04-2011 12:08 edited on: 21-04-2011 12:09	> Второй это монтирование дисков как папок. Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это. Положение могут спасти точки перехода NTFS (symbolic links вроде они называются), но не весь софт их поддерживает и данные с ними убить можно запросто. А вот полный путь в NameInCache - это очень здорово, спасибо.

(0002216) vdemidov (manager) 21-04-2011 12:22	>Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это. Если эти диски тома TrueCrypt отдельные для каждой карты, то вполне аккуратно.

(0002243) Papazol (reporter) 22-04-2011 10:18	Я попробовал на одной карте работать с трукриптовским файлом-контейнером. Всё получилось, тормозов не заметно. Но есть один недостаток: мало букв в латинском алфавите, чтобы каждой карте присвоить свой диск. Придётся объединять несколько карт в один диск. Но главное - что можно будет этот диск-файл скинуть хоть на DVD, хоть на флешку и отнести куда-либо, не тратя время на упаковку-распаковку.

(0002249) gpsMax (manager) 22-04-2011 12:08 edited on: 22-04-2011 12:11	Кстати говоря, не все контейнеры одинаково полезны. Я долго использовал майкрософтовский vhd способом, описанным на форуме. Но, во-первых, его затруднительно использовать под семёркой, нет родных дров под неё. И, во-вторых, чуть-чуть сыпятся данные, очень-очень редко, но, согласитесь неприятно видеть даже один битый тайл на сто тысяч - моя примерная оценка. В трукрипте потери данных не было замечено и работает он так же шустро, несмотря на лишнее шифрование. Я к тому, что при переходе на контейнер/БД нужно будет смотреть, как всё это заработает под нагрузкой, по скорости и надёжности.

(0002698) gpsMax (manager) 26-05-2011 20:02	Ещё соображение: автор SAS4WinCE придумал и реализовал сжатый формат контейнера, что-то типа zip, но оптимизированного под тайлы. Если этот формат понравится, можно импортировать эту идею вплоть до кусков кода.

(0002702) vdemidov (manager) 27-05-2011 05:11	Ну если кто-то покажет описание этого формата, а еще лучше исходники, то почему бы нет. Боюсь только у нас разные стратегии работы с кэшем. У него неизменный кэш, к которому идет только доступ на чтение, а у нас докачиваемый, генерируемый и тд контент.

(0003092) v_max (reporter) 30-06-2011 05:35	Для кэша самой планеты врядли подойдет.. н еориентирован он на добавление или удаление А вот экспорт в него было-бы здорово сделать.. Я пытался с дельфями разобраться (как с инструментом и средой) чтобы плагин написать... но не осилил ;( Могу сорцы паковщика выложить .. писано на дотнете.

(0004639) zed (manager) 26-12-2011 18:48	Сделал новый тип кэша на базе BerkeleyDB. Предварительно структура такая: <ZOOM>\<X/1024>\<X/256>.<Y/256>.db Т.е. получается, что стандартные сасовские подпапки сохраняются в отдельные файлы БД, причём в каждой БД будет не более 65536 файлов (квадрат в 256256 тайлов). Поддерживаются все операции (чтение/запись/удаление), информация об отсутствующих тайлах (.tne) сохраняется в отдельные БД с расширением .tne вместо .db (сортируются аналогично).

(0004640) vasketsov (manager) 26-12-2011 19:11	>BerkeleyDB А насколько тяжело будет сделать, чтобы работа с хранилищем тайлов была ТОЛЬКО через хранимые процедуры? Ну и соответственно через ODBC их гонять на любом серваке в локальной сети.

(0004641) zed (manager) 26-12-2011 19:16	Э.. я вообще не понимаю о чём ты :) Про сеть могу сказать только, что эта БД разрешает многопользовательский доступ только в пределах системы, т.е. грубо говоря, несколько копий программы могут нормально работать с одним кэшем, а вот если кто-то начнёт ещё и по локалке в неё подгружать, то быть беде.

(0004643) vasketsov (manager) 26-12-2011 20:10	Я про запись тайлов во "взрослые" СУБД типа oracle, mssql, sybase,... Вот у меня например и так сервак Sybase ASE крутится - фигли ему "простаивать"? А гигабитная локалка навряд ли сильно проиграет нжмд. А легко может даже и выиграть, всё же СУБД хранит и кэширует мелкие файлики лучше чем ФС.

(0004646) zed (manager) 26-12-2011 20:18	А, ну так никаких проблем. Нужно всего 5 функций: read, write, delete, exist и get_file_name (последняя чисто чтоб юзеру показать, какой конкретно тайл обрабатывается). И вперёд :) Только, красивше, конечно, этот момент сделать плагином, а то и код замусорится да и exe-ха будет расти не по дням, а по часам (в случае с MySQL надо подключать компонент, который + пару Мб точно докинет, и это не считая dll-ки).

(0004647) vasketsov (manager) 26-12-2011 20:28	>в случае с MySQL надо подключать компонент точно? я потому и написал про ODBC, чтобы было пофигу куда писать, читать и т.п. впрочем, если сервер не поддерживает хранимые процедуры и маппинг параметров, могут быть особенности. но по идее код один на всех будет, в этом плане несколько типов кэшей дают куда больший оверхэд. ну да в общем ладно, погляжу на досуге, мне сейчас достаточно подтверждения некой "автономности" перечисленных функций, и скажем так отсутствия сильного "связывания" с остальным кодом, дабы не зря тратить время в этом направлении. ну а коли всё просто и "выделяемо" - будем думать.

(0004648) vdemidov (manager) 26-12-2011 21:07	Там еще проблема, что пока нет механизма переключения типа кэша на лету без перезапуска программы.

(0004649) Garl (manager) 27-12-2011 05:08	может пригодится : http://componentace.com/absolute_database_features.htm

(0004650) vdemidov (manager) 27-12-2011 06:06	> может пригодится : http://componentace.com/absolute_database_features.htm Когда его выпустят под GPL будем смотреть. А пока увы.

(0004652) zed (manager) 27-12-2011 09:43	Может кто подскажет, какой выбрать дефолтный размер страницы (pagesize) для БД? Диапазон возможных значений: 512 байт - 64 Кб. Вот тут расписано про это http://pybsddb.sourceforge.net/ref/am_conf/pagesize.html Я по-умолчанию поставил 64k, но БД получается слегка пухлой и может быть чуть ли не в 2 раза больше, чем собственно записанные в неё данные. Приаттачил exe с дефолтным значением 512 байт + утилитку, которая показывает статистику по отдельно-взятой БД. Расшифровка статистики тут: http://pybsddb.sourceforge.net/api_c/db_stat.html (смотреть для Btree). И к слову, в GoogleMV, которая тоже когда-то юзала беркли, страница была 1024 байт.

(0004655) vasketsov (manager) 27-12-2011 11:41	>дефолтный размер страницы Ставь 4k (почти всегда будет оптимально) или 8k (только если есть реально широкие таблицы). Всё что больше - реально имеет смысл только для OLAP. Это относится к "взрослым" БД, у тебя же тут могут быть особенности, но очевидно лишь в плане снижения размера страницы. Я б больше 4k даже не тестил. Впрочем 512 я б тоже не стал, выбери 1k или 2k да и загони туда для теста яндексссатЪ.

(0004656) zed (manager) 27-12-2011 12:16	>только если есть реально широкие таблицы Кхм, а тут нету таблиц вообще, тут блобы только. И целиком блобы не влезут в страницу, вплоть до 32k. А если блоб в страницу не влазит, то невлезающая часть пишется в так называемые overflow страницы. А вот интересная математика: скачал в SAS регион 33*33 тайла (всего 1089), по завершении SAS написал, что загружено 16.1 МБ, эти тайлы легли в БД и заняли там 17.2 МБ (это при pagesize=512) или 18.3 МБ (при pagesize=4k). Эти же тайлы, распакованные в родной формат кэша SAS уже занимают 22,7 МБ (а на диске так вообще 34,0 МБ). Собственно, вообще не понятно почему в распакованном варианте они весят 22 МБ (если это без учёта размера кластера), ну да ладно. Выходит, что с точки зрения размера БД, оптимальной будет страница в 512 байт, но с точки зрения быстродействия, скорее всего это будет не очень оптимально (число страниц возрастает в разы). Без профайлера походу не разобраться...

(0004657) vdemidov (manager) 27-12-2011 13:04	Ну то что с точки зрения размера 512 лучше было понятно сразу. А вот что бы понять разницу в скорости нужно писать отдельные тесты

(0004660) Tolik (manager) 27-12-2011 14:50	О, очень нужная фича! Что-то я не понял, как его включить. Поставил Default cache type = BerkeleyDB, перегрузил программу, поелозил по карте - никаких файлов db не увидел. Хотя в zmp CacheType не определён. Кстати, какой CacheType в zmp соотв. BerkeleyDB?

(0004661) vdemidov (manager) 27-12-2011 14:52	Я кажется уже писал что переключения на новый формат на лету пока нет. Смена типа кэша только после перезапуска программы.

(0004662) Tolik (manager) 27-12-2011 14:58 edited on: 27-12-2011 15:04	Оказывается, CacheType=2 был почему-то указан в maps.ini. После нажатия кнопки "All by default" в настройках карты эта строка стёрлась, появилась директория cache_db. Поначалу туда стали писаться png, но после ещё одного рестарта появились наконец-то db! Хорошо, потестируем :) Конвертер форматов SAS.Planet -> BerkeleyDB писать будем? Открыл бы хотелку, да это к Планете уже не относится.. P.S. теперь в maps.ini пишется CacheType=6 (это ответ на мой предыдущий вопрос). А нафига он туда вообще пишется?

(0004663) zed (manager) 27-12-2011 15:10	>Кстати, какой CacheType в zmp соотв. BerkeleyDB 6 >Конвертер форматов SAS.Planet -> BerkeleyDB писать будем? Будем, наверное )

(0004664) Tolik (manager) 27-12-2011 15:15	Интересно, а CacheType=5 - это что? Вы уж напишите конвертер, очень просим :) (сорри за офтопик)

(0004665) vdemidov (manager) 27-12-2011 15:17	CacheType=5 Это кэш Google Earth

(0004677) Tolik (manager) 28-12-2011 05:16	Какие существуют утилиты для работы с такими db? Например, посмотреть содержимое, удалить/добавить тайл в БД и т.п.?

(0004679) vdemidov (manager) 28-12-2011 06:06	Скорее всего утилит нету. Наверное нужно сменить расширение с ".db" на что-то типа ".sas_db" и сделать wcx плагин для Total Commander.

(0004680) zed (manager) 28-12-2011 06:41	А смысл вообще что-то делать вручную внутри БД?

(0004681) vdemidov (manager) 28-12-2011 07:09	Ну это уже другой вопрос. Но ИМХО сменить расширение все-таки стоит.

(0004682) Tolik (manager) 28-12-2011 07:11	Например, .sdb Ну взять и закинуть туду тотал коммандером свой старый кэш... Или удалить какие-то тайлы...

(0004685) zed (manager) 28-12-2011 09:02	Можно и .sdb + нужно сортировку по папкам наверное переделать (вопрос - как) и определиться с дополнительными полями в БД. Сейчас там сохраняется X,Y (key), размер тайла, дата создания тайла ну и собственно, сам тайл. Т.е. вся та же информация, что и в текущем тайловом кэше. Что ещё туда можно/нужно записать? Забить на всякий случай ещё текстовое поле для версии тайла, авось когда и пригодится?

(0004686) Tolik (manager) 28-12-2011 09:18 edited on: 28-12-2011 09:19	> нужно сортировку по папкам наверное переделать Почему нет Y/1024? Какое макс. кол-во файлов в папке X/1024? > Забить на всякий случай ещё текстовое поле не помешает, пожалуй

(0004697) zed (manager) 28-12-2011 16:55	В папке X/1024 должно быть не более 1024 папки, в каждой из которых по 16k файлов БД. Если ввести ещё сортировку по Y/1024, то в итоге, в каждой папке у нас будет всего по 16 файлов БД. Можно ввести сортировку не по 1024, а по 256 элементов, тогда в каждой папке будет одинаковое число подпапок/файлов БД (256), но получится избыточное количество папок... Это если я не ошибаюсь в прикидках.

(0004698) Tolik (manager) 28-12-2011 17:29	> В папке X/1024 должно быть не более 1024 папки Не, что-то напутали. Сейчас в папке Х/1024 лежат файлы db. Например, z20\309\1236.640.db Поэтому я подумал, что файлов может быть очень много. А сколько именно - не соображу.

(0004699) zed (manager) 28-12-2011 17:31 edited on: 28-12-2011 17:35	В приведенном примере папка X/1024 это папка 309 и да, в ней будет не более 16k файлов БД. А в каждом файле БД лежит 64k тайлов.

(0004701) zed (manager) 28-12-2011 18:22	>На зуме 24 2^24 тайлов Не, по стороне X на определённом зуме 2^(z-1) тайлов, т.е. на 24-м зуме у нас (2^23)*(2^23)

(0004702) Tolik (manager) 28-12-2011 18:44	Блин, всё сначала. На 24-м зуме всего (2^23)*(2^23)= 2^46 тайлов (охренеть как много) В файле db 2^16 тайлов Всего 2^46 / 2^16 = 2^30 файлов db Если сделать папку X/1024, в ней будет 2^30 / 2^10 = 2^20 файлов = миллион - это много. Значит, нужна папка Y/1024, в ней будет 2^10 = 1024 файла БД. Или опять ошибся?

(0004703) zed (manager) 28-12-2011 18:59 edited on: 28-12-2011 19:06	Похоже на правду. P.S. А один файл БД весит примерно 1,5 Gb, так что для 24-го зума нам нужно... 1024*1024 Tb :)

(0004705) Tolik (manager) 28-12-2011 20:57	Всё-таки, кажется, ошибся. Если сделать папку X/1024, таких папок будет 2^23 / 1024 = 2^13. Cледовательно, в каждой папке будет 2^30 / 2^13 = 2^17 файлов = 131072 - это не много. :-\

(0004715) Tolik (manager) 29-12-2011 08:40	Кстати, в операцию копирования не забудьте добавить новый формат.

(0004718) zed (manager) 29-12-2011 13:40	Таки папку Y/1024 наверное добавлю на всякий случай.

(0004722) Tolik (manager) 29-12-2011 15:21 edited on: 29-12-2011 15:28	Это мне тоже нравится, т.к. симметрично как-то. Но в папках почти всегда будет ровно 1 файл, максимум 16 (если я опять ничего не напутал). Может, как-то так? z<Z>\<X/4096>\<Y/4096>\<X/256>.<Y/256>.sdb В этом случае уменьшится число папок. Максимум будет 2К папок, в папке макс. 256 файлов - красота :)

(0004724) Garl (manager) 29-12-2011 16:08	мужчины, а чем собственно плохо большое количество папок? всётаки аля классический кэш как то приятней.

(0004725) Tolik (manager) 29-12-2011 16:17	Ну чем меньше, тем лучше... Много файлов/директорий - много места тратится напрасно на хранение всего этого, много времени на копирование и т.д.

(0004727) Garl (manager) 29-12-2011 16:25	на спичках (папках) экономить?

(0004728) Tolik (manager) 29-12-2011 16:33	Ну а почему бы не сэкономить? Ради чего вобще БД? Именно чтобы избавиться от миллионов маленьких файлов. А какой плюс в привычной структуре?

(0004746) vasketsov (manager) 30-12-2011 14:38	>много времени на копирование это пока не надо внутрь файлов при копировании лезть. как только копирование в существующий кэш потребуют слить 2 файлика в один - там ещё бабка надвое сказала что быстрее будет.

(0004747) Fetser (reporter) 30-12-2011 15:48	Попробовал сравнить размеры папок при старом и новом кэш. При увеличении количества тайлов начинает сильно проигрывать вариант с базой данных. См рис. (слева новый формат) Это неизбежная плата за то что вместо большого количества маленьких файлов один большой?

(0004748) Tolik (manager) 30-12-2011 18:28	Здесь же выше Zed про это писал: http://sasgis.org/mantis/view.php?id=124#c4652 Проверьте то же самое на приаттаченной версии SASPlanet.db.512.zip, интересно, что получится. Также интересно узнать, сколько реально места занимают все эти файлы с учётом кластеров.

(0004749) Fetser (reporter) 30-12-2011 19:37	Проделал тоже самое для кластера 512 картинку приложил (512 слева)

(0004750) Tolik (manager) 30-12-2011 20:03	Можно подробнее? 1. Что слева и что справа на картинках 1 и 2? 2. Что означают цифры: общий размер папки с учётом кластеров (файловой системы) или без? 3. Если с учётом, то какой размер кластера? 4. Как получили разные виды кэша?

(0004751) Fetser (reporter) 30-12-2011 20:25	На всех картинках яндекс карты На первой картинке справа кэш старый (на диске 127 Мб диск созданный TrueCrypt размер кластера 512) слева новый кеш в виде базы данных файл SAS.Planet.Nightly.4747 (на диске 240 Мб кластер 4 кБ) на второй картинке справа новый кэш файл SAS.Planet.Nightly.4747 (на диске 240 Мб кластер 4 кБ) слева новый кеш файл SASPlanet.db.512 (на диске 140 Мб кластер 4 кБ)

(0004752) zed (manager) 30-12-2011 22:03	>при старом и новом кэш Это не _новый_ кэш, а _ещё_один_ кэш и не претендует на кэш по-умолчанию. >Это неизбежная плата Ну так а как вы думали, естественно. Ведь в БД помимо самих тайлов нужно ещё и служебную информацию где-то хранить (а вы, кстати, ещё сравните с учётом MFT таблицы - на миллионах тайлов она ведь тоже изрядно тяжёлая). По поводу pagesize: уже провёл кое-какие тесты и размер в 1k выглядит довольно не плохо, но надо ещё по-плотнее посмотреть.

(0004754) Tolik (manager) 31-12-2011 09:13	Ну почему же не претендует. Через некоторое время, когда всё будет доделано и хорошо проверено, можно сделать по умолчанию. Потому что миллионы файлов - это очень плохо. Интересно, какие тесты проведены, какие результаты? Надо ли ещё что-то затестировать?

(0004755) vasketsov (manager) 31-12-2011 12:10	Я может глупость спрошу, но тем не менее, этот формат будет соответствовать формату кэша для RMaps или нет? Если да, может так его и обозвать?

(0004756) zed (manager) 31-12-2011 13:06 edited on: 31-12-2011 13:09	>Интересно, какие тесты проведены, какие результаты? Результаты будут оглашены и тестовую утилитку тоже выложу, чтоб каждый желающий мог поиграться с параметрами. >будет соответствовать формату кэша для RMaps или нет А что у него там за формат? Я как-то и без понятия вообще. P.S. Что-то этот тикет перерастает в какую-то матроску, может вынести обсуждение на форум?

(0004757) Tolik (manager) 31-12-2011 14:08	Если не ошибаюсь, Rmaps - SQLite, т.е. другой формат. Зачем выносить, пусть обсуждение будет тут, пока не resolved.

(0004758) Fetser (reporter) 31-12-2011 18:01 edited on: 31-12-2011 18:03	Когда экспериментировал с файлом SASPlanet.db.512 При ПКМ Операции с выделенной областью постоянно вылетала ошибка, на работоспособность программы это не влияло, но на всякий случай прикладываю elf (кэш каждый раз удалял полностью, то есть это не из за того что существовал кэш созданный другим файлом)

(0004759) Tolik (manager) 01-01-2012 15:34 edited on: 01-01-2012 17:04	Версия 4758. 1. В меню Параметры карты переключение типа кэша требует перезапуска. Т.е. в моём случае стоит по умолчанию Беркли, для одной карты (скачанной ранее) ставлю Сас, карта появляется только после перезапуска. 2. При копировании в формат Сас к пути добавляется директория с именем кэша, а при копировании в формат Беркли нет. 3. В целом всё супер. Pagesize 1k. Размер исходного кэша в формате Сас - 430 MB, с учётом кластеров 490 МБ, 30318 файлов (кластер 4K). После копирования в Беркли - 458 МБ, с учётом кластеров 458 МБ, 14 файлов. 4. После обратной конверсии (копирования того же кэша из Беркли в Сас) получаем в точности тот же набор файлов (что не может не радовать!)

(0004760) Fetser (reporter) 01-01-2012 20:00	Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту (не дав заполнению полностью нарисоваться)То карта перестаёт подгружаться (в кэш она точно есть) Даже если отключить карту заполнения слоя, то всё равно карта перестаёт появляется на экране. Виден только тот участок что был первоначально, не помогает и смена масштаба. Новый зум не появляется. Спасает только перезагрузка программы.

(0004761) zed (manager) 01-01-2012 20:37	>Когда экспериментировал с файлом SASPlanet.db.512 При ПКМ Операции с выделенной областью постоянно вылетала ошибка, Да, было. Уже пофиксили. К кэшу никак не относится >1. В меню Параметры карты переключение типа кэша требует перезапуска Да, и не важно какой тип кэша выбран. Т.е. это в отдельную хотелку/баг оформляйте. >2. При копировании в формат Сас к пути добавляется директория Исправил >Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту Насколько большая разница между текущим зумом и зумом для которого строится карта? P.S. Завтрашняя сборка не будет понимать сегодняшний кэш, я там ещё одно поле добавил (надеюсь, больше уже добавлять/менять ничего не придётся).

(0004762) Fetser (reporter) 02-01-2012 06:15	>Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту Насколько большая разница между текущим зумом и зумом для которого строится карта? Карта была 7 зум, карта заполнения 11

(0004763) zed (manager) 02-01-2012 07:53	Прикрепил результаты тестов и утилитку (инструкция в readme). Что могу сказать: в этом тесте (и на моей системе) операции Read и Exists проходят практически молниеносно при любом значении pagesize и на них как бы можно внимание не заострять. Наиболее длительные операции это Write и Del, и что интересно, при pagesize=1024 оказываются наиболее быстрыми (причём, даже в разы!). Ещё тёмной лошадкой остаётся размер озу-шного кэша БД (cachesize), я его всюду ставил на дефолт (256k), а при увеличении наоборот наблюдаются тормоза. И ещё отрицательный момент большого кэша - при закрытии программе придётся "висеть", пока он не будет сброшен на винт, и соответственно чем больше кэш, тем дольше висим. С другой стороны, при множественных обращениях к одному и тому же тайлу бОльший кэш будет только на пользу. Так что тут ХЗ.

(0004764) T_Im (reporter) 02-01-2012 10:38	Может стоит опционально добавить еще один тип кеша - "все в одном файле"? Такой тип кеш более удобен с точки зрения пользователя для обмена и хранения небольших снимков и областей.

(0004765) Fetser (reporter) 02-01-2012 11:29 edited on: 02-01-2012 11:51	Версия 4759 Увы баг с нежеланием отображать карту из нового кэш остался, даже нет необходимости включать карту заполнения слоя, достаточно несколько раз поменять масштаб и карта перестаёт перерисовываться. Может это из за того что у меня всего 1 Гб ОЗУ? С удивлением обнаружил что суммарный обьём кеша Беркли меньше сумарного состоящего из тайлов (3134 Мб-Беркли, 3384 Мб-тайловый)и это без учёта размещения на диске. Если с учётом, то выигрыш ещё больше. Если 40 файлов беркли сжать ещё архиватором для переноса (zip)то размер вообще 2933 Мб

(0004766) zed (manager) 02-01-2012 13:16	Словил похожего глюка: новые тайлы в режиме просмотра перестали загружаться, но при этом закачки по выделению идут без проблем, так же, если выбрать в менюшке "Загрузить тайл в кэш", то он загружается и отображается. А так же, если переключиться на другую карту, то она работает нормально.

(0004767) Tolik (manager) 02-01-2012 13:21 edited on: 02-01-2012 13:35	> новые тайлы в режиме просмотра перестали загружаться Такое было и раньше, до появления нового кэша. Уже как минимум месяц замечаю. Надо открыть новый баг.

(0004768) Fetser (reporter) 02-01-2012 13:55	Поочерёдно сравнивал то со старым кешем, то с новым (конечно перезапуская программу) Со старым завесить программу не получается всё работает. А с новым она вешается через несколько минут интенсивного сдвигания карты и смены масштаба. В процессах после того как программа повисла и я ничего более от неё не требую процесс sasplanet грузит процессор на 40% и так продолжается бесконечно долго. ни сменить карту ни загрузить тайл не получается, но само поле легко двигается (определяю по меткам)

(0004769) Tolik (manager) 02-01-2012 13:56 edited on: 02-01-2012 14:11	У меня такого не было ни разу. ОЗУ тоже 1 МБ. Правда, кэш не такой большой. Пожалуй, стоит тоже открыть отдельный баг репорт.

Users who viewed this issue
User List	Anonymous (6806x)
Total Views	6806
Last View	21-11-2024 13:31

Issue History
Date Modified	Username	Field	Change
24-09-2010 13:20	Fighter	New Issue
24-09-2010 13:57	vdemidov	Note Added: 0000228
24-09-2010 13:57	vdemidov	Assigned To	=> vdemidov
24-09-2010 13:57	vdemidov	Status	new => acknowledged
24-09-2010 13:58	vdemidov	Assigned To	vdemidov =>
24-09-2010 13:58	vdemidov	Target Version	=> 40xxxx
13-10-2010 08:02	vdemidov	Target Version	40xxxx => 29xxxx
13-10-2010 11:19	gpsMax	Tag Attached: плагины
13-10-2010 11:19	gpsMax	Tag Attached: кэш
14-10-2010 08:00	Tikh	Note Added: 0000343
14-10-2010 08:20	vdemidov	Note Added: 0000344
05-11-2010 05:36	DJ VK	Note Added: 0000395
06-04-2011 23:41	gpsMax	Note Edited: 0000228	View Revisions
06-04-2011 23:44	gpsMax	Note Added: 0001578
11-04-2011 07:11	vdemidov	Status	acknowledged => confirmed
20-04-2011 10:23	gpsMax	Relationship added	related to 0000653
20-04-2011 10:24	gpsMax	Summary	Вместо тысяч файлов -- несколько больших БД => Вместо тысяч файлов - несколько больших БД
20-04-2011 10:24	gpsMax	Description Updated	View Revisions
20-04-2011 10:26	Tikh	Note Added: 0002129
20-04-2011 12:01	gpsMax	Note Added: 0002143
20-04-2011 16:49	Papazol	Note Added: 0002145
20-04-2011 16:58	vdemidov	Note Added: 0002148
21-04-2011 11:18	Papazol	Note Added: 0002207
21-04-2011 11:32	vdemidov	Note Added: 0002209
21-04-2011 11:37	Papazol	Note Added: 0002211
21-04-2011 12:08	gpsMax	Note Added: 0002215
21-04-2011 12:09	gpsMax	Note Edited: 0002215	View Revisions
21-04-2011 12:22	vdemidov	Note Added: 0002216
22-04-2011 10:18	Papazol	Note Added: 0002243
22-04-2011 12:08	gpsMax	Note Added: 0002249
22-04-2011 12:10	gpsMax	Note Edited: 0002249	View Revisions
22-04-2011 12:11	gpsMax	Note Edited: 0002249	View Revisions
22-04-2011 12:11	gpsMax	Note Edited: 0002249	View Revisions
26-05-2011 20:02	gpsMax	Note Added: 0002698
27-05-2011 05:11	vdemidov	Note Added: 0002702
29-05-2011 12:16	vdemidov	Relationship replaced	parent of 0000653
03-06-2011 11:05	gpsMax	Relationship added	related to 0000783
30-06-2011 05:35	v_max	Note Added: 0003092
26-12-2011 18:48	zed	Note Added: 0004639
26-12-2011 19:11	vasketsov	Note Added: 0004640
26-12-2011 19:16	zed	Note Added: 0004641
26-12-2011 20:10	vasketsov	Note Added: 0004643
26-12-2011 20:18	zed	Note Added: 0004646
26-12-2011 20:28	vasketsov	Note Added: 0004647
26-12-2011 21:07	vdemidov	Note Added: 0004648
27-12-2011 05:08	Garl	Note Added: 0004649
27-12-2011 06:06	vdemidov	Note Added: 0004650
27-12-2011 09:43	zed	File Added: SASPlanet.db.512.zip
27-12-2011 09:43	zed	File Added: db_stat.zip
27-12-2011 09:43	zed	Note Added: 0004652
27-12-2011 11:41	vasketsov	Note Added: 0004655
27-12-2011 12:16	zed	Note Added: 0004656
27-12-2011 13:04	vdemidov	Note Added: 0004657
27-12-2011 14:50	Tolik	Note Added: 0004660
27-12-2011 14:52	vdemidov	Note Added: 0004661
27-12-2011 14:58	Tolik	Note Added: 0004662
27-12-2011 15:04	Tolik	Note Edited: 0004662	View Revisions
27-12-2011 15:10	zed	Note Added: 0004663
27-12-2011 15:15	Tolik	Note Added: 0004664
27-12-2011 15:17	vdemidov	Note Added: 0004665
28-12-2011 05:16	Tolik	Note Added: 0004677
28-12-2011 06:06	vdemidov	Note Added: 0004679
28-12-2011 06:41	zed	Note Added: 0004680
28-12-2011 07:09	vdemidov	Note Added: 0004681
28-12-2011 07:11	Tolik	Note Added: 0004682
28-12-2011 09:02	zed	Note Added: 0004685
28-12-2011 09:18	Tolik	Note Added: 0004686
28-12-2011 09:19	Tolik	Note Edited: 0004686	View Revisions
28-12-2011 16:55	zed	Note Added: 0004697
28-12-2011 17:29	Tolik	Note Added: 0004698
28-12-2011 17:31	zed	Note Added: 0004699
28-12-2011 17:32	zed	Note Edited: 0004699	View Revisions
28-12-2011 17:35	zed	Note Edited: 0004699	View Revisions
28-12-2011 18:15	Tolik	Note Added: 0004700
28-12-2011 18:22	zed	Note Added: 0004701
28-12-2011 18:25	Tolik	Note Deleted: 0004700
28-12-2011 18:44	Tolik	Note Added: 0004702
28-12-2011 18:59	zed	Note Added: 0004703
28-12-2011 19:06	zed	Note Edited: 0004703	View Revisions
28-12-2011 20:43	Tolik	Note Added: 0004704
28-12-2011 20:44	Tolik	Note Deleted: 0004704
28-12-2011 20:57	Tolik	Note Added: 0004705
29-12-2011 08:40	Tolik	Note Added: 0004715
29-12-2011 13:40	zed	Note Added: 0004718
29-12-2011 15:21	Tolik	Note Added: 0004722
29-12-2011 15:28	Tolik	Note Edited: 0004722	View Revisions
29-12-2011 16:08	Garl	Note Added: 0004724
29-12-2011 16:17	Tolik	Note Added: 0004725
29-12-2011 16:25	Garl	Note Added: 0004727
29-12-2011 16:33	Tolik	Note Added: 0004728
30-12-2011 14:38	vasketsov	Note Added: 0004746
30-12-2011 15:48	Fetser	Note Added: 0004747
30-12-2011 15:48	Fetser	File Added: 1.jpg
30-12-2011 18:28	Tolik	Note Added: 0004748
30-12-2011 19:37	Fetser	Note Added: 0004749
30-12-2011 19:37	Fetser	File Added: 2.jpg
30-12-2011 20:03	Tolik	Note Added: 0004750
30-12-2011 20:25	Fetser	Note Added: 0004751
30-12-2011 22:03	zed	Note Added: 0004752
31-12-2011 09:13	Tolik	Note Added: 0004754
31-12-2011 12:10	vasketsov	Note Added: 0004755
31-12-2011 13:06	zed	Note Added: 0004756
31-12-2011 13:09	zed	Note Edited: 0004756	View Revisions
31-12-2011 14:08	Tolik	Note Added: 0004757
31-12-2011 18:01	Fetser	Note Added: 0004758
31-12-2011 18:02	Fetser	File Added: SASPlanet.db.512.elf
31-12-2011 18:03	Fetser	Note Edited: 0004758	View Revisions
01-01-2012 15:34	Tolik	Note Added: 0004759
01-01-2012 15:57	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 16:01	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 16:03	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 16:48	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 16:48	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 16:59	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 16:59	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 17:04	Tolik	Note Edited: 0004759	View Revisions
01-01-2012 20:00	Fetser	Note Added: 0004760
01-01-2012 20:37	zed	Note Added: 0004761
02-01-2012 06:15	Fetser	Note Added: 0004762
02-01-2012 07:37	zed	File Added: profile_results.7z
02-01-2012 07:38	zed	File Added: bdb_stress_test.7z
02-01-2012 07:53	zed	Note Added: 0004763
02-01-2012 10:38	T_Im	Note Added: 0004764
02-01-2012 11:29	Fetser	Note Added: 0004765
02-01-2012 11:51	Fetser	Note Edited: 0004765	View Revisions
02-01-2012 13:16	zed	Note Added: 0004766
02-01-2012 13:21	Tolik	Note Added: 0004767
02-01-2012 13:32	Tolik	Note Edited: 0004767	View Revisions
02-01-2012 13:35	Tolik	Note Edited: 0004767	View Revisions
02-01-2012 13:55	Fetser	Note Added: 0004768
02-01-2012 13:56	Tolik	Note Added: 0004769
02-01-2012 14:11	Tolik	Note Edited: 0004769	View Revisions
03-01-2012 08:17	Tolik	Relationship added	related to 0001095
03-01-2012 10:45	zed	Status	confirmed => resolved
03-01-2012 10:45	zed	Fixed in Version	=> 24xxxx
03-01-2012 10:45	zed	Resolution	open => fixed
03-01-2012 10:45	zed	Assigned To	=> zed
23-01-2012 08:20	vdemidov	Relationship deleted	parent of 0000653
23-01-2012 08:20	vdemidov	Relationship added	related to 0000653
23-01-2012 08:20	vdemidov	Fixed in Version	24xxxx => 120808
23-01-2012 08:20	vdemidov	Target Version	29xxxx => 120808
05-07-2012 05:38	vdemidov	Summary	Вместо тысяч файлов - несколько больших БД => Тайлохранилище в виде набора баз BerkeleyDB
07-07-2012 10:06	gpsMax	Tag Attached: БД
10-10-2012 11:44	Tolik	Status	resolved => closed

SASGIS