SASGIS - SAS.Планета
View Issue Details
0000124SAS.Планета[All Projects] Хотелкаpublic24-09-2010 13:2010-10-2012 11:44
Fighter 
zed 
highmajorhave not tried
closedfixed 
WindowsXPSP3
100707 
120808120808 
0000124: Тайлохранилище в виде набора баз BerkeleyDB
Думаю, очень пригодилось бы, потому что большие количества файлов плохо копируются, медленее обрабатываются и занимают больше места
БД, кэш, плагины
related to 0000783closed gpsMax Относительные пути кэша 
related to 0001095closed zed При использовании кэша Беркли программа перестаёт отображать карту 
related to 0000653confirmed  Отображать тайлы из архива 
zip SASPlanet.db.512.zip (2,722,536) 27-12-2011 09:43
http://www.sasgis.org/mantis/file_download.php?file_id=555&type=bug
zip db_stat.zip (234,803) 27-12-2011 09:43
http://www.sasgis.org/mantis/file_download.php?file_id=556&type=bug
jpg 1.jpg (15,054) 30-12-2011 15:48
http://www.sasgis.org/mantis/file_download.php?file_id=568&type=bug
jpg

jpg 2.jpg (14,385) 30-12-2011 19:37
http://www.sasgis.org/mantis/file_download.php?file_id=569&type=bug
jpg

? SASPlanet.db.512.elf (39,448) 31-12-2011 18:02
http://www.sasgis.org/mantis/file_download.php?file_id=570&type=bug
7z profile_results.7z (2,583) 02-01-2012 07:37
http://www.sasgis.org/mantis/file_download.php?file_id=571&type=bug
7z bdb_stress_test.7z (2,399,685) 02-01-2012 07:38
http://www.sasgis.org/mantis/file_download.php?file_id=572&type=bug
Issue History
24-09-2010 13:20FighterNew Issue
24-09-2010 13:57vdemidovNote Added: 0000228
24-09-2010 13:57vdemidovAssigned To => vdemidov
24-09-2010 13:57vdemidovStatusnew => acknowledged
24-09-2010 13:58vdemidovAssigned Tovdemidov =>
24-09-2010 13:58vdemidovTarget Version => 40xxxx
13-10-2010 08:02vdemidovTarget Version40xxxx => 29xxxx
13-10-2010 11:19gpsMaxTag Attached: плагины
13-10-2010 11:19gpsMaxTag Attached: кэш
14-10-2010 08:00TikhNote Added: 0000343
14-10-2010 08:20vdemidovNote Added: 0000344
05-11-2010 05:36DJ VKNote Added: 0000395
06-04-2011 23:41gpsMaxNote Edited: 0000228bug_revision_view_page.php?bugnote_id=228#r560
06-04-2011 23:44gpsMaxNote Added: 0001578
11-04-2011 07:11vdemidovStatusacknowledged => confirmed
20-04-2011 10:23gpsMaxRelationship addedrelated to 0000653
20-04-2011 10:24gpsMaxSummaryВместо тысяч файлов -- несколько больших БД => Вместо тысяч файлов - несколько больших БД
20-04-2011 10:24gpsMaxDescription Updatedbug_revision_view_page.php?rev_id=894#r894
20-04-2011 10:26TikhNote Added: 0002129
20-04-2011 12:01gpsMaxNote Added: 0002143
20-04-2011 16:49PapazolNote Added: 0002145
20-04-2011 16:58vdemidovNote Added: 0002148
21-04-2011 11:18PapazolNote Added: 0002207
21-04-2011 11:32vdemidovNote Added: 0002209
21-04-2011 11:37PapazolNote Added: 0002211
21-04-2011 12:08gpsMaxNote Added: 0002215
21-04-2011 12:09gpsMaxNote Edited: 0002215bug_revision_view_page.php?bugnote_id=2215#r949
21-04-2011 12:22vdemidovNote Added: 0002216
22-04-2011 10:18PapazolNote Added: 0002243
22-04-2011 12:08gpsMaxNote Added: 0002249
22-04-2011 12:10gpsMaxNote Edited: 0002249bug_revision_view_page.php?bugnote_id=2249#r975
22-04-2011 12:11gpsMaxNote Edited: 0002249bug_revision_view_page.php?bugnote_id=2249#r976
22-04-2011 12:11gpsMaxNote Edited: 0002249bug_revision_view_page.php?bugnote_id=2249#r977
26-05-2011 20:02gpsMaxNote Added: 0002698
27-05-2011 05:11vdemidovNote Added: 0002702
29-05-2011 12:16vdemidovRelationship replacedparent of 0000653
03-06-2011 11:05gpsMaxRelationship addedrelated to 0000783
30-06-2011 05:35v_maxNote Added: 0003092
26-12-2011 18:48zedNote Added: 0004639
26-12-2011 19:11vasketsovNote Added: 0004640
26-12-2011 19:16zedNote Added: 0004641
26-12-2011 20:10vasketsovNote Added: 0004643
26-12-2011 20:18zedNote Added: 0004646
26-12-2011 20:28vasketsovNote Added: 0004647
26-12-2011 21:07vdemidovNote Added: 0004648
27-12-2011 05:08GarlNote Added: 0004649
27-12-2011 06:06vdemidovNote Added: 0004650
27-12-2011 09:43zedFile Added: SASPlanet.db.512.zip
27-12-2011 09:43zedFile Added: db_stat.zip
27-12-2011 09:43zedNote Added: 0004652
27-12-2011 11:41vasketsovNote Added: 0004655
27-12-2011 12:16zedNote Added: 0004656
27-12-2011 13:04vdemidovNote Added: 0004657
27-12-2011 14:50TolikNote Added: 0004660
27-12-2011 14:52vdemidovNote Added: 0004661
27-12-2011 14:58TolikNote Added: 0004662
27-12-2011 15:04TolikNote Edited: 0004662bug_revision_view_page.php?bugnote_id=4662#r2301
27-12-2011 15:10zedNote Added: 0004663
27-12-2011 15:15TolikNote Added: 0004664
27-12-2011 15:17vdemidovNote Added: 0004665
28-12-2011 05:16TolikNote Added: 0004677
28-12-2011 06:06vdemidovNote Added: 0004679
28-12-2011 06:41zedNote Added: 0004680
28-12-2011 07:09vdemidovNote Added: 0004681
28-12-2011 07:11TolikNote Added: 0004682
28-12-2011 09:02zedNote Added: 0004685
28-12-2011 09:18TolikNote Added: 0004686
28-12-2011 09:19TolikNote Edited: 0004686bug_revision_view_page.php?bugnote_id=4686#r2309
28-12-2011 16:55zedNote Added: 0004697
28-12-2011 17:29TolikNote Added: 0004698
28-12-2011 17:31zedNote Added: 0004699
28-12-2011 17:32zedNote Edited: 0004699bug_revision_view_page.php?bugnote_id=4699#r2315
28-12-2011 17:35zedNote Edited: 0004699bug_revision_view_page.php?bugnote_id=4699#r2316
28-12-2011 18:15TolikNote Added: 0004700
28-12-2011 18:22zedNote Added: 0004701
28-12-2011 18:25TolikNote Deleted: 0004700
28-12-2011 18:44TolikNote Added: 0004702
28-12-2011 18:59zedNote Added: 0004703
28-12-2011 19:06zedNote Edited: 0004703bug_revision_view_page.php?bugnote_id=4703#r2318
28-12-2011 20:43TolikNote Added: 0004704
28-12-2011 20:44TolikNote Deleted: 0004704
28-12-2011 20:57TolikNote Added: 0004705
29-12-2011 08:40TolikNote Added: 0004715
29-12-2011 13:40zedNote Added: 0004718
29-12-2011 15:21TolikNote Added: 0004722
29-12-2011 15:28TolikNote Edited: 0004722bug_revision_view_page.php?bugnote_id=4722#r2329
29-12-2011 16:08GarlNote Added: 0004724
29-12-2011 16:17TolikNote Added: 0004725
29-12-2011 16:25GarlNote Added: 0004727
29-12-2011 16:33TolikNote Added: 0004728
30-12-2011 14:38vasketsovNote Added: 0004746
30-12-2011 15:48FetserNote Added: 0004747
30-12-2011 15:48FetserFile Added: 1.jpg
30-12-2011 18:28TolikNote Added: 0004748
30-12-2011 19:37FetserNote Added: 0004749
30-12-2011 19:37FetserFile Added: 2.jpg
30-12-2011 20:03TolikNote Added: 0004750
30-12-2011 20:25FetserNote Added: 0004751
30-12-2011 22:03zedNote Added: 0004752
31-12-2011 09:13TolikNote Added: 0004754
31-12-2011 12:10vasketsovNote Added: 0004755
31-12-2011 13:06zedNote Added: 0004756
31-12-2011 13:09zedNote Edited: 0004756bug_revision_view_page.php?bugnote_id=4756#r2344
31-12-2011 14:08TolikNote Added: 0004757
31-12-2011 18:01FetserNote Added: 0004758
31-12-2011 18:02FetserFile Added: SASPlanet.db.512.elf
31-12-2011 18:03FetserNote Edited: 0004758bug_revision_view_page.php?bugnote_id=4758#r2346
01-01-2012 15:34TolikNote Added: 0004759
01-01-2012 15:57TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2348
01-01-2012 16:01TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2349
01-01-2012 16:03TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2350
01-01-2012 16:48TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2351
01-01-2012 16:48TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2352
01-01-2012 16:59TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2353
01-01-2012 16:59TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2354
01-01-2012 17:04TolikNote Edited: 0004759bug_revision_view_page.php?bugnote_id=4759#r2355
01-01-2012 20:00FetserNote Added: 0004760
01-01-2012 20:37zedNote Added: 0004761
02-01-2012 06:15FetserNote Added: 0004762
02-01-2012 07:37zedFile Added: profile_results.7z
02-01-2012 07:38zedFile Added: bdb_stress_test.7z
02-01-2012 07:53zedNote Added: 0004763
02-01-2012 10:38T_ImNote Added: 0004764
02-01-2012 11:29FetserNote Added: 0004765
02-01-2012 11:51FetserNote Edited: 0004765bug_revision_view_page.php?bugnote_id=4765#r2357
02-01-2012 13:16zedNote Added: 0004766
02-01-2012 13:21TolikNote Added: 0004767
02-01-2012 13:32TolikNote Edited: 0004767bug_revision_view_page.php?bugnote_id=4767#r2359
02-01-2012 13:35TolikNote Edited: 0004767bug_revision_view_page.php?bugnote_id=4767#r2360
02-01-2012 13:55FetserNote Added: 0004768
02-01-2012 13:56TolikNote Added: 0004769
02-01-2012 14:11TolikNote Edited: 0004769bug_revision_view_page.php?bugnote_id=4769#r2362
03-01-2012 08:17TolikRelationship addedrelated to 0001095
03-01-2012 10:45zedStatusconfirmed => resolved
03-01-2012 10:45zedFixed in Version => 24xxxx
03-01-2012 10:45zedResolutionopen => fixed
03-01-2012 10:45zedAssigned To => zed
23-01-2012 08:20vdemidovRelationship deletedparent of 0000653
23-01-2012 08:20vdemidovRelationship addedrelated to 0000653
23-01-2012 08:20vdemidovFixed in Version24xxxx => 120808
23-01-2012 08:20vdemidovTarget Version29xxxx => 120808
05-07-2012 05:38vdemidovSummaryВместо тысяч файлов - несколько больших БД => Тайлохранилище в виде набора баз BerkeleyDB
07-07-2012 10:06gpsMaxTag Attached: БД
10-10-2012 11:44TolikStatusresolved => closed

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

(0000343)
Tikh   
14-10-2010 08:00   
Скажите, а когда примерно ждать поддержку плагинов?
(0000344)
vdemidov   
14-10-2010 08:20   
Как только так и сразу
(0000395)
DJ VK   
05-11-2010 05:36   
Пожелание. прошу учесть. Не надо делать 2-3 базы данных очень большого размера. Прошу
1. разбить базу на среднего размера файлы. в файле 16k или 64k тайлов. Чтобы разбиение было по квадратам, а размер одного файла не превышал 1-1,2 ГБ. тогда легче обмениваться.
2. Организовать возможность раздельного хранения файлов баз - создается список путей, и при работе в автомате в соответствии с очередностью последовательно они заполняются, забив один диск (например задается квота свободного места. достигнута - переход к след папке) идем на другой. а пользователь может переносить при желании файлы баз между этими путями.
Когда будет мультизакачка слой за слоем автоматическое забивание дисков может и пригодиться.
3. Если квоты исчерпаны пользователь получает уведомление - некуда скачивать.
(0001578)
gpsMax   
06-04-2011 23:44   
Насчёт медленного копирования - на форуме было подробное обсуждение данного вопроса. Лучшим обходным решением было признано создание контейнеров в TrueCrypt, но это именно временное обходное решение. Хотя, надо сказать, работает неплохо.
(0002129)
Tikh   
20-04-2011 10:26   
Не поделитесь ссылочкой на форум, где обсуждают True Crypt?
(0002143)
gpsMax   
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   
20-04-2011 16:49   
Есть такая идея: сохранять кэш каждой карты в совершенно отдельную папку. Чтобы не только название папки NameInCache задавалось, но и полный путь. Это позволит, например, задать в том же TrueCrypt для каждого кэша отдельный контейнер. И обрабатывать содержимое кэша будет проще, так как файлы будут меньшего размера.
(0002148)
vdemidov   
20-04-2011 16:58   
И кто вам мешает?
(0002207)
Papazol   
21-04-2011 11:18   
Отсутствие многих знаний. Как я считаю, путь ко всему кэшу программы прописывается в настройках, и он един для всех карт. Различия только в названиях папок, но лежат-то они все в одной. Не догоняю чего-то я?
(0002209)
vdemidov   
21-04-2011 11:32   
В NameInCache вполне можно прописывать полный путь. Это первый вариант. Второй это монтирование дисков как папок.
(0002211)
Papazol   
21-04-2011 11:37   
Надо попробовать по первому варианту. Второй не подходит мне, так как нужно обратное: смонтировать папки, точнее, файлы, как диски.
(0002215)
gpsMax   
21-04-2011 12:08   
(edited on: 21-04-2011 12:09)
> Второй это монтирование дисков как папок.
Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это. Положение могут спасти точки перехода NTFS (symbolic links вроде они называются), но не весь софт их поддерживает и данные с ними убить можно запросто.

А вот полный путь в NameInCache - это очень здорово, спасибо.

(0002216)
vdemidov   
21-04-2011 12:22   
>Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это.
Если эти диски тома TrueCrypt отдельные для каждой карты, то вполне аккуратно.
(0002243)
Papazol   
22-04-2011 10:18   
Я попробовал на одной карте работать с трукриптовским файлом-контейнером. Всё получилось, тормозов не заметно. Но есть один недостаток: мало букв в латинском алфавите, чтобы каждой карте присвоить свой диск. Придётся объединять несколько карт в один диск. Но главное - что можно будет этот диск-файл скинуть хоть на DVD, хоть на флешку и отнести куда-либо, не тратя время на упаковку-распаковку.
(0002249)
gpsMax   
22-04-2011 12:08   
(edited on: 22-04-2011 12:11)
Кстати говоря, не все контейнеры одинаково полезны. Я долго использовал майкрософтовский vhd способом, описанным на форуме. Но, во-первых, его затруднительно использовать под семёркой, нет родных дров под неё. И, во-вторых, чуть-чуть сыпятся данные, очень-очень редко, но, согласитесь неприятно видеть даже один битый тайл на сто тысяч - моя примерная оценка. В трукрипте потери данных не было замечено и работает он так же шустро, несмотря на лишнее шифрование. Я к тому, что при переходе на контейнер/БД нужно будет смотреть, как всё это заработает под нагрузкой, по скорости и надёжности.

(0002698)
gpsMax   
26-05-2011 20:02   
Ещё соображение: автор SAS4WinCE придумал и реализовал сжатый формат контейнера, что-то типа zip, но оптимизированного под тайлы. Если этот формат понравится, можно импортировать эту идею вплоть до кусков кода.
(0002702)
vdemidov   
27-05-2011 05:11   
Ну если кто-то покажет описание этого формата, а еще лучше исходники, то почему бы нет. Боюсь только у нас разные стратегии работы с кэшем. У него неизменный кэш, к которому идет только доступ на чтение, а у нас докачиваемый, генерируемый и тд контент.
(0003092)
v_max   
30-06-2011 05:35   
Для кэша самой планеты врядли подойдет.. н еориентирован он на добавление
или удаление

А вот экспорт в него было-бы здорово сделать..
Я пытался с дельфями разобраться (как с инструментом и средой)
чтобы плагин написать... но не осилил ;(

Могу сорцы паковщика выложить .. писано на дотнете.
(0004639)
zed   
26-12-2011 18:48   
Сделал новый тип кэша на базе BerkeleyDB.
Предварительно структура такая: <ZOOM>\<X/1024>\<X/256>.<Y/256>.db
Т.е. получается, что стандартные сасовские подпапки сохраняются в отдельные файлы БД, причём в каждой БД будет не более 65536 файлов (квадрат в 256*256 тайлов).
Поддерживаются все операции (чтение/запись/удаление), информация об отсутствующих тайлах (*.tne) сохраняется в отдельные БД с расширением *.tne вместо *.db (сортируются аналогично).
(0004640)
vasketsov   
26-12-2011 19:11   
>BerkeleyDB
А насколько тяжело будет сделать, чтобы работа с хранилищем тайлов была ТОЛЬКО через хранимые процедуры? Ну и соответственно через ODBC их гонять на любом серваке в локальной сети.
(0004641)
zed   
26-12-2011 19:16   
Э.. я вообще не понимаю о чём ты :)
Про сеть могу сказать только, что эта БД разрешает многопользовательский доступ только в пределах системы, т.е. грубо говоря, несколько копий программы могут нормально работать с одним кэшем, а вот если кто-то начнёт ещё и по локалке в неё подгружать, то быть беде.
(0004643)
vasketsov   
26-12-2011 20:10   
Я про запись тайлов во "взрослые" СУБД типа oracle, mssql, sybase,...
Вот у меня например и так сервак Sybase ASE крутится - фигли ему "простаивать"?
А гигабитная локалка навряд ли сильно проиграет нжмд. А легко может даже и выиграть, всё же СУБД хранит и кэширует мелкие файлики лучше чем ФС.
(0004646)
zed   
26-12-2011 20:18   
А, ну так никаких проблем. Нужно всего 5 функций: read, write, delete, exist и get_file_name (последняя чисто чтоб юзеру показать, какой конкретно тайл обрабатывается). И вперёд :)
Только, красивше, конечно, этот момент сделать плагином, а то и код замусорится да и exe-ха будет расти не по дням, а по часам (в случае с MySQL надо подключать компонент, который + пару Мб точно докинет, и это не считая dll-ки).
(0004647)
vasketsov   
26-12-2011 20:28   
>в случае с MySQL надо подключать компонент
точно? я потому и написал про ODBC, чтобы было пофигу куда писать, читать и т.п.
впрочем, если сервер не поддерживает хранимые процедуры и маппинг параметров, могут быть особенности. но по идее код один на всех будет, в этом плане несколько типов кэшей дают куда больший оверхэд.
ну да в общем ладно, погляжу на досуге, мне сейчас достаточно подтверждения некой "автономности" перечисленных функций, и скажем так отсутствия сильного "связывания" с остальным кодом, дабы не зря тратить время в этом направлении. ну а коли всё просто и "выделяемо" - будем думать.
(0004648)
vdemidov   
26-12-2011 21:07   
Там еще проблема, что пока нет механизма переключения типа кэша на лету без перезапуска программы.
(0004649)
Garl   
27-12-2011 05:08   
может пригодится : http://componentace.com/absolute_database_features.htm
(0004650)
vdemidov   
27-12-2011 06:06   
> может пригодится : http://componentace.com/absolute_database_features.htm
Когда его выпустят под GPL будем смотреть. А пока увы.
(0004652)
zed   
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   
27-12-2011 11:41   
>дефолтный размер страницы
Ставь 4k (почти всегда будет оптимально) или 8k (только если есть реально широкие таблицы). Всё что больше - реально имеет смысл только для OLAP. Это относится к "взрослым" БД, у тебя же тут могут быть особенности, но очевидно лишь в плане снижения размера страницы. Я б больше 4k даже не тестил. Впрочем 512 я б тоже не стал, выбери 1k или 2k да и загони туда для теста яндексссатЪ.
(0004656)
zed   
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   
27-12-2011 13:04   
Ну то что с точки зрения размера 512 лучше было понятно сразу. А вот что бы понять разницу в скорости нужно писать отдельные тесты
(0004660)
Tolik   
27-12-2011 14:50   
О, очень нужная фича!
Что-то я не понял, как его включить.
Поставил Default cache type = BerkeleyDB, перегрузил программу, поелозил по карте - никаких файлов db не увидел. Хотя в zmp CacheType не определён.

Кстати, какой CacheType в zmp соотв. BerkeleyDB?
(0004661)
vdemidov   
27-12-2011 14:52   
Я кажется уже писал что переключения на новый формат на лету пока нет. Смена типа кэша только после перезапуска программы.
(0004662)
Tolik   
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   
27-12-2011 15:10   
>Кстати, какой CacheType в zmp соотв. BerkeleyDB
6

>Конвертер форматов SAS.Planet -> BerkeleyDB писать будем?
Будем, наверное )
(0004664)
Tolik   
27-12-2011 15:15   
Интересно, а CacheType=5 - это что?
Вы уж напишите конвертер, очень просим :)
(сорри за офтопик)
(0004665)
vdemidov   
27-12-2011 15:17   
CacheType=5
Это кэш Google Earth
(0004677)
Tolik   
28-12-2011 05:16   
Какие существуют утилиты для работы с такими db?
Например, посмотреть содержимое, удалить/добавить тайл в БД и т.п.?
(0004679)
vdemidov   
28-12-2011 06:06   
Скорее всего утилит нету. Наверное нужно сменить расширение с ".db" на что-то типа ".sas_db" и сделать wcx плагин для Total Commander.
(0004680)
zed   
28-12-2011 06:41   
А смысл вообще что-то делать вручную внутри БД?
(0004681)
vdemidov   
28-12-2011 07:09   
Ну это уже другой вопрос. Но ИМХО сменить расширение все-таки стоит.
(0004682)
Tolik   
28-12-2011 07:11   
Например, .sdb

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

> Забить на всякий случай ещё текстовое поле
не помешает, пожалуй

(0004697)
zed   
28-12-2011 16:55   
В папке X/1024 должно быть не более 1024 папки, в каждой из которых по 16k файлов БД. Если ввести ещё сортировку по Y/1024, то в итоге, в каждой папке у нас будет всего по 16 файлов БД. Можно ввести сортировку не по 1024, а по 256 элементов, тогда в каждой папке будет одинаковое число подпапок/файлов БД (256), но получится избыточное количество папок...
Это если я не ошибаюсь в прикидках.
(0004698)
Tolik   
28-12-2011 17:29   
> В папке X/1024 должно быть не более 1024 папки
Не, что-то напутали. Сейчас в папке Х/1024 лежат файлы db.
Например, z20\309\1236.640.db
Поэтому я подумал, что файлов может быть очень много. А сколько именно - не соображу.
(0004699)
zed   
28-12-2011 17:31   
(edited on: 28-12-2011 17:35)
В приведенном примере папка X/1024 это папка 309 и да, в ней будет не более 16k файлов БД. А в каждом файле БД лежит 64k тайлов.

(0004701)
zed   
28-12-2011 18:22   
>На зуме 24 2^24 тайлов
Не, по стороне X на определённом зуме 2^(z-1) тайлов, т.е. на 24-м зуме у нас (2^23)*(2^23)
(0004702)
Tolik   
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   
28-12-2011 18:59   
(edited on: 28-12-2011 19:06)
Похоже на правду.

P.S. А один файл БД весит примерно 1,5 Gb, так что для 24-го зума нам нужно... 1024*1024 Tb :)

(0004705)
Tolik   
28-12-2011 20:57   
Всё-таки, кажется, ошибся.

Если сделать папку X/1024, таких папок будет 2^23 / 1024 = 2^13.
Cледовательно, в каждой папке будет 2^30 / 2^13 = 2^17 файлов = 131072 - это не много.
:-\
(0004715)
Tolik   
29-12-2011 08:40   
Кстати, в операцию копирования не забудьте добавить новый формат.
(0004718)
zed   
29-12-2011 13:40   
Таки папку Y/1024 наверное добавлю на всякий случай.
(0004722)
Tolik   
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   
29-12-2011 16:08   
мужчины, а чем собственно плохо большое количество папок?
всётаки аля классический кэш как то приятней.
(0004725)
Tolik   
29-12-2011 16:17   
Ну чем меньше, тем лучше...
Много файлов/директорий - много места тратится напрасно на хранение всего этого, много времени на копирование и т.д.
(0004727)
Garl   
29-12-2011 16:25   
на спичках (папках) экономить?
(0004728)
Tolik   
29-12-2011 16:33   
Ну а почему бы не сэкономить? Ради чего вобще БД? Именно чтобы избавиться от миллионов маленьких файлов.
А какой плюс в привычной структуре?
(0004746)
vasketsov   
30-12-2011 14:38   
>много времени на копирование
это пока не надо внутрь файлов при копировании лезть. как только копирование в существующий кэш потребуют слить 2 файлика в один - там ещё бабка надвое сказала что быстрее будет.
(0004747)
Fetser   
30-12-2011 15:48   
Попробовал сравнить размеры папок при старом и новом кэш. При увеличении количества тайлов начинает сильно проигрывать вариант с базой данных. См рис. (слева новый формат)
Это неизбежная плата за то что вместо большого количества маленьких файлов один большой?
(0004748)
Tolik   
30-12-2011 18:28   
Здесь же выше Zed про это писал:
http://sasgis.org/mantis/view.php?id=124#c4652
Проверьте то же самое на приаттаченной версии SASPlanet.db.512.zip, интересно, что получится.

Также интересно узнать, сколько реально места занимают все эти файлы с учётом кластеров.
(0004749)
Fetser   
30-12-2011 19:37   
Проделал тоже самое для кластера 512 картинку приложил (512 слева)
(0004750)
Tolik   
30-12-2011 20:03   
Можно подробнее?
1. Что слева и что справа на картинках 1 и 2?
2. Что означают цифры: общий размер папки с учётом кластеров (файловой системы) или без?
3. Если с учётом, то какой размер кластера?
4. Как получили разные виды кэша?
(0004751)
Fetser   
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   
30-12-2011 22:03   
>при старом и новом кэш
Это не _новый_ кэш, а _ещё_один_ кэш и не претендует на кэш по-умолчанию.

>Это неизбежная плата
Ну так а как вы думали, естественно. Ведь в БД помимо самих тайлов нужно ещё и служебную информацию где-то хранить (а вы, кстати, ещё сравните с учётом MFT таблицы - на миллионах тайлов она ведь тоже изрядно тяжёлая).

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

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

>будет соответствовать формату кэша для RMaps или нет
А что у него там за формат? Я как-то и без понятия вообще.

P.S. Что-то этот тикет перерастает в какую-то матроску, может вынести обсуждение на форум?

(0004757)
Tolik   
31-12-2011 14:08   
Если не ошибаюсь, Rmaps - SQLite, т.е. другой формат.

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

(0004759)
Tolik   
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   
01-01-2012 20:00   
Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту (не дав заполнению полностью нарисоваться)То карта перестаёт подгружаться (в кэш она точно есть) Даже если отключить карту заполнения слоя, то всё равно карта перестаёт появляется на экране. Виден только тот участок что был первоначально, не помогает и смена масштаба. Новый зум не появляется. Спасает только перезагрузка программы.
(0004761)
zed   
01-01-2012 20:37   
>Когда экспериментировал с файлом SASPlanet.db.512 При ПКМ Операции с выделенной областью постоянно вылетала ошибка,
Да, было. Уже пофиксили. К кэшу никак не относится

>1. В меню Параметры карты переключение типа кэша требует перезапуска
Да, и не важно какой тип кэша выбран. Т.е. это в отдельную хотелку/баг оформляйте.

>2. При копировании в формат Сас к пути добавляется директория
Исправил

>Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту
Насколько большая разница между текущим зумом и зумом для которого строится карта?

P.S. Завтрашняя сборка не будет понимать сегодняшний кэш, я там ещё одно поле добавил (надеюсь, больше уже добавлять/менять ничего не придётся).
(0004762)
Fetser   
02-01-2012 06:15   
>Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту
 Насколько большая разница между текущим зумом и зумом для которого строится карта?
Карта была 7 зум, карта заполнения 11
(0004763)
zed   
02-01-2012 07:53   
Прикрепил результаты тестов и утилитку (инструкция в readme).

Что могу сказать: в этом тесте (и на моей системе) операции Read и Exists проходят практически молниеносно при любом значении pagesize и на них как бы можно внимание не заострять. Наиболее длительные операции это Write и Del, и что интересно, при pagesize=1024 оказываются наиболее быстрыми (причём, даже в разы!). Ещё тёмной лошадкой остаётся размер озу-шного кэша БД (cachesize), я его всюду ставил на дефолт (256k), а при увеличении наоборот наблюдаются тормоза. И ещё отрицательный момент большого кэша - при закрытии программе придётся "висеть", пока он не будет сброшен на винт, и соответственно чем больше кэш, тем дольше висим. С другой стороны, при множественных обращениях к одному и тому же тайлу бОльший кэш будет только на пользу. Так что тут ХЗ.
(0004764)
T_Im   
02-01-2012 10:38   
Может стоит опционально добавить еще один тип кеша - "все в одном файле"? Такой тип кеш более удобен с точки зрения пользователя для обмена и хранения небольших снимков и областей.
(0004765)
Fetser   
02-01-2012 11:29   
(edited on: 02-01-2012 11:51)
Версия 4759 Увы баг с нежеланием отображать карту из нового кэш остался, даже нет необходимости включать карту заполнения слоя, достаточно несколько раз поменять масштаб и карта перестаёт перерисовываться. Может это из за того что у меня всего 1 Гб ОЗУ? С удивлением обнаружил что суммарный обьём кеша Беркли меньше сумарного состоящего из тайлов (3134 Мб-Беркли, 3384 Мб-тайловый)и это без учёта размещения на диске. Если с учётом, то выигрыш ещё больше. Если 40 файлов беркли сжать ещё архиватором для переноса (zip)то размер вообще 2933 Мб

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

(0004768)
Fetser   
02-01-2012 13:55   
Поочерёдно сравнивал то со старым кешем, то с новым (конечно перезапуская программу) Со старым завесить программу не получается всё работает. А с новым она вешается через несколько минут интенсивного сдвигания карты и смены масштаба. В процессах после того как программа повисла и я ничего более от неё не требую процесс sasplanet грузит процессор на 40% и так продолжается бесконечно долго. ни сменить карту ни загрузить тайл не получается, но само поле легко двигается (определяю по меткам)
(0004769)
Tolik   
02-01-2012 13:56   
(edited on: 02-01-2012 14:11)
У меня такого не было ни разу. ОЗУ тоже 1 МБ. Правда, кэш не такой большой.
Пожалуй, стоит тоже открыть отдельный баг репорт.