View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000124 | SAS.Планета | Хотелка / Feature request | public | 24-09-2010 13:20 | 10-10-2012 11:44 |
| Reporter | Fighter | Assigned To | zed | ||
| Priority | high | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Platform | Windows | OS | XP | OS Version | SP3 |
| Product Version | 100707 | ||||
| Target Version | 120808 | Fixed in Version | 120808 | ||
| Summary | 0000124: Тайлохранилище в виде набора баз BerkeleyDB | ||||
| Description | Думаю, очень пригодилось бы, потому что большие количества файлов плохо копируются, медленее обрабатываются и занимают больше места | ||||
| Tags | БД, кэш, плагины | ||||
| Attached Files | |||||
|
|
Всем хочется, и мне в том числе. Будет одновременно с поддержкой плагинов. |
|
|
Скажите, а когда примерно ждать поддержку плагинов? |
|
|
Как только так и сразу |
|
|
Пожелание. прошу учесть. Не надо делать 2-3 базы данных очень большого размера. Прошу 1. разбить базу на среднего размера файлы. в файле 16k или 64k тайлов. Чтобы разбиение было по квадратам, а размер одного файла не превышал 1-1,2 ГБ. тогда легче обмениваться. 2. Организовать возможность раздельного хранения файлов баз - создается список путей, и при работе в автомате в соответствии с очередностью последовательно они заполняются, забив один диск (например задается квота свободного места. достигнута - переход к след папке) идем на другой. а пользователь может переносить при желании файлы баз между этими путями. Когда будет мультизакачка слой за слоем автоматическое забивание дисков может и пригодиться. 3. Если квоты исчерпаны пользователь получает уведомление - некуда скачивать. |
|
|
Насчёт медленного копирования - на форуме было подробное обсуждение данного вопроса. Лучшим обходным решением было признано создание контейнеров в TrueCrypt, но это именно временное обходное решение. Хотя, надо сказать, работает неплохо. |
|
|
Не поделитесь ссылочкой на форум, где обсуждают True Crypt? |
|
|
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 |
|
|
Есть такая идея: сохранять кэш каждой карты в совершенно отдельную папку. Чтобы не только название папки NameInCache задавалось, но и полный путь. Это позволит, например, задать в том же TrueCrypt для каждого кэша отдельный контейнер. И обрабатывать содержимое кэша будет проще, так как файлы будут меньшего размера. |
|
|
И кто вам мешает? |
|
|
Отсутствие многих знаний. Как я считаю, путь ко всему кэшу программы прописывается в настройках, и он един для всех карт. Различия только в названиях папок, но лежат-то они все в одной. Не догоняю чего-то я? |
|
|
В NameInCache вполне можно прописывать полный путь. Это первый вариант. Второй это монтирование дисков как папок. |
|
|
Надо попробовать по первому варианту. Второй не подходит мне, так как нужно обратное: смонтировать папки, точнее, файлы, как диски. |
|
|
> Второй это монтирование дисков как папок. Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это. Положение могут спасти точки перехода NTFS (symbolic links вроде они называются), но не весь софт их поддерживает и данные с ними убить можно запросто. А вот полный путь в NameInCache - это очень здорово, спасибо. |
|
|
>Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это. Если эти диски тома TrueCrypt отдельные для каждой карты, то вполне аккуратно. |
|
|
Я попробовал на одной карте работать с трукриптовским файлом-контейнером. Всё получилось, тормозов не заметно. Но есть один недостаток: мало букв в латинском алфавите, чтобы каждой карте присвоить свой диск. Придётся объединять несколько карт в один диск. Но главное - что можно будет этот диск-файл скинуть хоть на DVD, хоть на флешку и отнести куда-либо, не тратя время на упаковку-распаковку. |
|
|
Кстати говоря, не все контейнеры одинаково полезны. Я долго использовал майкрософтовский vhd способом, описанным на форуме. Но, во-первых, его затруднительно использовать под семёркой, нет родных дров под неё. И, во-вторых, чуть-чуть сыпятся данные, очень-очень редко, но, согласитесь неприятно видеть даже один битый тайл на сто тысяч - моя примерная оценка. В трукрипте потери данных не было замечено и работает он так же шустро, несмотря на лишнее шифрование. Я к тому, что при переходе на контейнер/БД нужно будет смотреть, как всё это заработает под нагрузкой, по скорости и надёжности. |
|
|
Ещё соображение: автор SAS4WinCE придумал и реализовал сжатый формат контейнера, что-то типа zip, но оптимизированного под тайлы. Если этот формат понравится, можно импортировать эту идею вплоть до кусков кода. |
|
|
Ну если кто-то покажет описание этого формата, а еще лучше исходники, то почему бы нет. Боюсь только у нас разные стратегии работы с кэшем. У него неизменный кэш, к которому идет только доступ на чтение, а у нас докачиваемый, генерируемый и тд контент. |
|
|
Для кэша самой планеты врядли подойдет.. н еориентирован он на добавление или удаление А вот экспорт в него было-бы здорово сделать.. Я пытался с дельфями разобраться (как с инструментом и средой) чтобы плагин написать... но не осилил ;( Могу сорцы паковщика выложить .. писано на дотнете. |
|
|
Сделал новый тип кэша на базе BerkeleyDB. Предварительно структура такая: <ZOOM>\<X/1024>\<X/256>.<Y/256>.db Т.е. получается, что стандартные сасовские подпапки сохраняются в отдельные файлы БД, причём в каждой БД будет не более 65536 файлов (квадрат в 256*256 тайлов). Поддерживаются все операции (чтение/запись/удаление), информация об отсутствующих тайлах (*.tne) сохраняется в отдельные БД с расширением *.tne вместо *.db (сортируются аналогично). |
|
|
>BerkeleyDB А насколько тяжело будет сделать, чтобы работа с хранилищем тайлов была ТОЛЬКО через хранимые процедуры? Ну и соответственно через ODBC их гонять на любом серваке в локальной сети. |
|
|
Э.. я вообще не понимаю о чём ты :) Про сеть могу сказать только, что эта БД разрешает многопользовательский доступ только в пределах системы, т.е. грубо говоря, несколько копий программы могут нормально работать с одним кэшем, а вот если кто-то начнёт ещё и по локалке в неё подгружать, то быть беде. |
|
|
Я про запись тайлов во "взрослые" СУБД типа oracle, mssql, sybase,... Вот у меня например и так сервак Sybase ASE крутится - фигли ему "простаивать"? А гигабитная локалка навряд ли сильно проиграет нжмд. А легко может даже и выиграть, всё же СУБД хранит и кэширует мелкие файлики лучше чем ФС. |
|
|
А, ну так никаких проблем. Нужно всего 5 функций: read, write, delete, exist и get_file_name (последняя чисто чтоб юзеру показать, какой конкретно тайл обрабатывается). И вперёд :) Только, красивше, конечно, этот момент сделать плагином, а то и код замусорится да и exe-ха будет расти не по дням, а по часам (в случае с MySQL надо подключать компонент, который + пару Мб точно докинет, и это не считая dll-ки). |
|
|
>в случае с MySQL надо подключать компонент точно? я потому и написал про ODBC, чтобы было пофигу куда писать, читать и т.п. впрочем, если сервер не поддерживает хранимые процедуры и маппинг параметров, могут быть особенности. но по идее код один на всех будет, в этом плане несколько типов кэшей дают куда больший оверхэд. ну да в общем ладно, погляжу на досуге, мне сейчас достаточно подтверждения некой "автономности" перечисленных функций, и скажем так отсутствия сильного "связывания" с остальным кодом, дабы не зря тратить время в этом направлении. ну а коли всё просто и "выделяемо" - будем думать. |
|
|
Там еще проблема, что пока нет механизма переключения типа кэша на лету без перезапуска программы. |
|
|
может пригодится : http://componentace.com/absolute_database_features.htm |
|
|
> может пригодится : http://componentace.com/absolute_database_features.htm Когда его выпустят под GPL будем смотреть. А пока увы. |
|
|
Может кто подскажет, какой выбрать дефолтный размер страницы (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 байт. |
|
|
>дефолтный размер страницы Ставь 4k (почти всегда будет оптимально) или 8k (только если есть реально широкие таблицы). Всё что больше - реально имеет смысл только для OLAP. Это относится к "взрослым" БД, у тебя же тут могут быть особенности, но очевидно лишь в плане снижения размера страницы. Я б больше 4k даже не тестил. Впрочем 512 я б тоже не стал, выбери 1k или 2k да и загони туда для теста яндексссатЪ. |
|
|
>только если есть реально широкие таблицы Кхм, а тут нету таблиц вообще, тут блобы только. И целиком блобы не влезут в страницу, вплоть до 32k. А если блоб в страницу не влазит, то невлезающая часть пишется в так называемые overflow страницы. А вот интересная математика: скачал в SAS регион 33*33 тайла (всего 1089), по завершении SAS написал, что загружено 16.1 МБ, эти тайлы легли в БД и заняли там 17.2 МБ (это при pagesize=512) или 18.3 МБ (при pagesize=4k). Эти же тайлы, распакованные в родной формат кэша SAS уже занимают 22,7 МБ (а на диске так вообще 34,0 МБ). Собственно, вообще не понятно почему в распакованном варианте они весят 22 МБ (если это без учёта размера кластера), ну да ладно. Выходит, что с точки зрения размера БД, оптимальной будет страница в 512 байт, но с точки зрения быстродействия, скорее всего это будет не очень оптимально (число страниц возрастает в разы). Без профайлера походу не разобраться... |
|
|
Ну то что с точки зрения размера 512 лучше было понятно сразу. А вот что бы понять разницу в скорости нужно писать отдельные тесты |
|
|
О, очень нужная фича! Что-то я не понял, как его включить. Поставил Default cache type = BerkeleyDB, перегрузил программу, поелозил по карте - никаких файлов db не увидел. Хотя в zmp CacheType не определён. Кстати, какой CacheType в zmp соотв. BerkeleyDB? |
|
|
Я кажется уже писал что переключения на новый формат на лету пока нет. Смена типа кэша только после перезапуска программы. |
|
|
Оказывается, CacheType=2 был почему-то указан в maps.ini. После нажатия кнопки "All by default" в настройках карты эта строка стёрлась, появилась директория cache_db. Поначалу туда стали писаться png, но после ещё одного рестарта появились наконец-то db! Хорошо, потестируем :) Конвертер форматов SAS.Planet -> BerkeleyDB писать будем? Открыл бы хотелку, да это к Планете уже не относится.. P.S. теперь в maps.ini пишется CacheType=6 (это ответ на мой предыдущий вопрос). А нафига он туда вообще пишется? |
|
|
>Кстати, какой CacheType в zmp соотв. BerkeleyDB 6 >Конвертер форматов SAS.Planet -> BerkeleyDB писать будем? Будем, наверное ) |
|
|
Интересно, а CacheType=5 - это что? Вы уж напишите конвертер, очень просим :) (сорри за офтопик) |
|
|
CacheType=5 Это кэш Google Earth |
|
|
Какие существуют утилиты для работы с такими db? Например, посмотреть содержимое, удалить/добавить тайл в БД и т.п.? |
|
|
Скорее всего утилит нету. Наверное нужно сменить расширение с ".db" на что-то типа ".sas_db" и сделать wcx плагин для Total Commander. |
|
|
А смысл вообще что-то делать вручную внутри БД? |
|
|
Ну это уже другой вопрос. Но ИМХО сменить расширение все-таки стоит. |
|
|
Например, .sdb Ну взять и закинуть туду тотал коммандером свой старый кэш... Или удалить какие-то тайлы... |
|
|
Можно и .sdb + нужно сортировку по папкам наверное переделать (вопрос - как) и определиться с дополнительными полями в БД. Сейчас там сохраняется X,Y (key), размер тайла, дата создания тайла ну и собственно, сам тайл. Т.е. вся та же информация, что и в текущем тайловом кэше. Что ещё туда можно/нужно записать? Забить на всякий случай ещё текстовое поле для версии тайла, авось когда и пригодится? |
|
|
> нужно сортировку по папкам наверное переделать Почему нет Y/1024? Какое макс. кол-во файлов в папке X/1024? > Забить на всякий случай ещё текстовое поле не помешает, пожалуй |
|
|
В папке X/1024 должно быть не более 1024 папки, в каждой из которых по 16k файлов БД. Если ввести ещё сортировку по Y/1024, то в итоге, в каждой папке у нас будет всего по 16 файлов БД. Можно ввести сортировку не по 1024, а по 256 элементов, тогда в каждой папке будет одинаковое число подпапок/файлов БД (256), но получится избыточное количество папок... Это если я не ошибаюсь в прикидках. |
|
|
> В папке X/1024 должно быть не более 1024 папки Не, что-то напутали. Сейчас в папке Х/1024 лежат файлы db. Например, z20\309\1236.640.db Поэтому я подумал, что файлов может быть очень много. А сколько именно - не соображу. |
|
|
В приведенном примере папка X/1024 это папка 309 и да, в ней будет не более 16k файлов БД. А в каждом файле БД лежит 64k тайлов. |
|
|
>На зуме 24 2^24 тайлов Не, по стороне X на определённом зуме 2^(z-1) тайлов, т.е. на 24-м зуме у нас (2^23)*(2^23) |
|
|
Блин, всё сначала. На 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 файла БД. Или опять ошибся? |
|
|
Похоже на правду. P.S. А один файл БД весит примерно 1,5 Gb, так что для 24-го зума нам нужно... 1024*1024 Tb :) |
|
|
Всё-таки, кажется, ошибся. Если сделать папку X/1024, таких папок будет 2^23 / 1024 = 2^13. Cледовательно, в каждой папке будет 2^30 / 2^13 = 2^17 файлов = 131072 - это не много. :-\ |
|
|
Кстати, в операцию копирования не забудьте добавить новый формат. |
|
|
Таки папку Y/1024 наверное добавлю на всякий случай. |
|
|
Это мне тоже нравится, т.к. симметрично как-то. Но в папках почти всегда будет ровно 1 файл, максимум 16 (если я опять ничего не напутал). Может, как-то так? z<Z>\<X/4096>\<Y/4096>\<X/256>.<Y/256>.sdb В этом случае уменьшится число папок. Максимум будет 2К папок, в папке макс. 256 файлов - красота :) |
|
|
мужчины, а чем собственно плохо большое количество папок? всётаки аля классический кэш как то приятней. |
|
|
Ну чем меньше, тем лучше... Много файлов/директорий - много места тратится напрасно на хранение всего этого, много времени на копирование и т.д. |
|
|
на спичках (папках) экономить? |
|
|
Ну а почему бы не сэкономить? Ради чего вобще БД? Именно чтобы избавиться от миллионов маленьких файлов. А какой плюс в привычной структуре? |
|
|
>много времени на копирование это пока не надо внутрь файлов при копировании лезть. как только копирование в существующий кэш потребуют слить 2 файлика в один - там ещё бабка надвое сказала что быстрее будет. |
|
|
Попробовал сравнить размеры папок при старом и новом кэш. При увеличении количества тайлов начинает сильно проигрывать вариант с базой данных. См рис. (слева новый формат) Это неизбежная плата за то что вместо большого количества маленьких файлов один большой? |
|
|
Здесь же выше Zed про это писал: http://sasgis.org/mantis/view.php?id=124#c4652 Проверьте то же самое на приаттаченной версии SASPlanet.db.512.zip, интересно, что получится. Также интересно узнать, сколько реально места занимают все эти файлы с учётом кластеров. |
|
|
Проделал тоже самое для кластера 512 картинку приложил (512 слева) |
|
|
Можно подробнее? 1. Что слева и что справа на картинках 1 и 2? 2. Что означают цифры: общий размер папки с учётом кластеров (файловой системы) или без? 3. Если с учётом, то какой размер кластера? 4. Как получили разные виды кэша? |
|
|
На всех картинках яндекс карты На первой картинке справа кэш старый (на диске 127 Мб диск созданный TrueCrypt размер кластера 512) слева новый кеш в виде базы данных файл SAS.Planet.Nightly.4747 (на диске 240 Мб кластер 4 кБ) на второй картинке справа новый кэш файл SAS.Planet.Nightly.4747 (на диске 240 Мб кластер 4 кБ) слева новый кеш файл SASPlanet.db.512 (на диске 140 Мб кластер 4 кБ) |
|
|
>при старом и новом кэш Это не _новый_ кэш, а _ещё_один_ кэш и не претендует на кэш по-умолчанию. >Это неизбежная плата Ну так а как вы думали, естественно. Ведь в БД помимо самих тайлов нужно ещё и служебную информацию где-то хранить (а вы, кстати, ещё сравните с учётом MFT таблицы - на миллионах тайлов она ведь тоже изрядно тяжёлая). По поводу pagesize: уже провёл кое-какие тесты и размер в 1k выглядит довольно не плохо, но надо ещё по-плотнее посмотреть. |
|
|
Ну почему же не претендует. Через некоторое время, когда всё будет доделано и хорошо проверено, можно сделать по умолчанию. Потому что миллионы файлов - это очень плохо. Интересно, какие тесты проведены, какие результаты? Надо ли ещё что-то затестировать? |
|
|
Я может глупость спрошу, но тем не менее, этот формат будет соответствовать формату кэша для RMaps или нет? Если да, может так его и обозвать? |
|
|
>Интересно, какие тесты проведены, какие результаты? Результаты будут оглашены и тестовую утилитку тоже выложу, чтоб каждый желающий мог поиграться с параметрами. >будет соответствовать формату кэша для RMaps или нет А что у него там за формат? Я как-то и без понятия вообще. P.S. Что-то этот тикет перерастает в какую-то матроску, может вынести обсуждение на форум? |
|
|
Если не ошибаюсь, Rmaps - SQLite, т.е. другой формат. Зачем выносить, пусть обсуждение будет тут, пока не resolved. |
|
|
Когда экспериментировал с файлом SASPlanet.db.512 При ПКМ Операции с выделенной областью постоянно вылетала ошибка, на работоспособность программы это не влияло, но на всякий случай прикладываю elf (кэш каждый раз удалял полностью, то есть это не из за того что существовал кэш созданный другим файлом) |
|
|
Версия 4758. 1. В меню Параметры карты переключение типа кэша требует перезапуска. Т.е. в моём случае стоит по умолчанию Беркли, для одной карты (скачанной ранее) ставлю Сас, карта появляется только после перезапуска. 2. При копировании в формат Сас к пути добавляется директория с именем кэша, а при копировании в формат Беркли нет. 3. В целом всё супер. Pagesize 1k. Размер исходного кэша в формате Сас - 430 MB, с учётом кластеров 490 МБ, 30318 файлов (кластер 4K). После копирования в Беркли - 458 МБ, с учётом кластеров 458 МБ, 14 файлов. 4. После обратной конверсии (копирования того же кэша из Беркли в Сас) получаем в точности тот же набор файлов (что не может не радовать!) |
|
|
Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту (не дав заполнению полностью нарисоваться)То карта перестаёт подгружаться (в кэш она точно есть) Даже если отключить карту заполнения слоя, то всё равно карта перестаёт появляется на экране. Виден только тот участок что был первоначально, не помогает и смена масштаба. Новый зум не появляется. Спасает только перезагрузка программы. |
|
|
>Когда экспериментировал с файлом SASPlanet.db.512 При ПКМ Операции с выделенной областью постоянно вылетала ошибка, Да, было. Уже пофиксили. К кэшу никак не относится >1. В меню Параметры карты переключение типа кэша требует перезапуска Да, и не важно какой тип кэша выбран. Т.е. это в отдельную хотелку/баг оформляйте. >2. При копировании в формат Сас к пути добавляется директория Исправил >Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту Насколько большая разница между текущим зумом и зумом для которого строится карта? P.S. Завтрашняя сборка не будет понимать сегодняшний кэш, я там ещё одно поле добавил (надеюсь, больше уже добавлять/менять ничего не придётся). |
|
|
>Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту Насколько большая разница между текущим зумом и зумом для которого строится карта? Карта была 7 зум, карта заполнения 11 |
|
|
Прикрепил результаты тестов и утилитку (инструкция в readme). Что могу сказать: в этом тесте (и на моей системе) операции Read и Exists проходят практически молниеносно при любом значении pagesize и на них как бы можно внимание не заострять. Наиболее длительные операции это Write и Del, и что интересно, при pagesize=1024 оказываются наиболее быстрыми (причём, даже в разы!). Ещё тёмной лошадкой остаётся размер озу-шного кэша БД (cachesize), я его всюду ставил на дефолт (256k), а при увеличении наоборот наблюдаются тормоза. И ещё отрицательный момент большого кэша - при закрытии программе придётся "висеть", пока он не будет сброшен на винт, и соответственно чем больше кэш, тем дольше висим. С другой стороны, при множественных обращениях к одному и тому же тайлу бОльший кэш будет только на пользу. Так что тут ХЗ. |
|
|
Может стоит опционально добавить еще один тип кеша - "все в одном файле"? Такой тип кеш более удобен с точки зрения пользователя для обмена и хранения небольших снимков и областей. |
|
|
Версия 4759 Увы баг с нежеланием отображать карту из нового кэш остался, даже нет необходимости включать карту заполнения слоя, достаточно несколько раз поменять масштаб и карта перестаёт перерисовываться. Может это из за того что у меня всего 1 Гб ОЗУ? С удивлением обнаружил что суммарный обьём кеша Беркли меньше сумарного состоящего из тайлов (3134 Мб-Беркли, 3384 Мб-тайловый)и это без учёта размещения на диске. Если с учётом, то выигрыш ещё больше. Если 40 файлов беркли сжать ещё архиватором для переноса (zip)то размер вообще 2933 Мб |
|
|
Словил похожего глюка: новые тайлы в режиме просмотра перестали загружаться, но при этом закачки по выделению идут без проблем, так же, если выбрать в менюшке "Загрузить тайл в кэш", то он загружается и отображается. А так же, если переключиться на другую карту, то она работает нормально. |
|
|
> новые тайлы в режиме просмотра перестали загружаться Такое было и раньше, до появления нового кэша. Уже как минимум месяц замечаю. Надо открыть новый баг. |
|
|
Поочерёдно сравнивал то со старым кешем, то с новым (конечно перезапуская программу) Со старым завесить программу не получается всё работает. А с новым она вешается через несколько минут интенсивного сдвигания карты и смены масштаба. В процессах после того как программа повисла и я ничего более от неё не требую процесс sasplanet грузит процессор на 40% и так продолжается бесконечно долго. ни сменить карту ни загрузить тайл не получается, но само поле легко двигается (определяю по меткам) |
|
|
У меня такого не было ни разу. ОЗУ тоже 1 МБ. Правда, кэш не такой большой. Пожалуй, стоит тоже открыть отдельный баг репорт. |
| 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 | => 45xxxx |
| 13-10-2010 08:02 | vdemidov | Target Version | 45xxxx => 44xxxx |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 22-04-2011 12:11 | gpsMax | Note Edited: 0002249 | |
| 22-04-2011 12:11 | gpsMax | Note Edited: 0002249 | |
| 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 | |
| 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 | |
| 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 | |
| 28-12-2011 17:35 | zed | Note Edited: 0004699 | |
| 28-12-2011 18:22 | zed | Note Added: 0004701 | |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 01-01-2012 15:34 | Tolik | Note Added: 0004759 | |
| 01-01-2012 15:57 | Tolik | Note Edited: 0004759 | |
| 01-01-2012 16:01 | Tolik | Note Edited: 0004759 | |
| 01-01-2012 16:03 | Tolik | Note Edited: 0004759 | |
| 01-01-2012 16:48 | Tolik | Note Edited: 0004759 | |
| 01-01-2012 16:48 | Tolik | Note Edited: 0004759 | |
| 01-01-2012 16:59 | Tolik | Note Edited: 0004759 | |
| 01-01-2012 16:59 | Tolik | Note Edited: 0004759 | |
| 01-01-2012 17:04 | Tolik | Note Edited: 0004759 | |
| 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 | |
| 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 | |
| 02-01-2012 13:35 | Tolik | Note Edited: 0004767 | |
| 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 | |
| 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 | => 41xxxx |
| 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 | 41xxxx => 120808 |
| 23-01-2012 08:20 | vdemidov | Target Version | 44xxxx => 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 |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |