MaPro

Обсуждение различной информации связанной с картографией, а так же сторонние программные продукты

Модераторы: Tolik, zed

Re: MaPro

Сообщение Alexander » 13 дек 2008, 01:28

zed писал(а):Alexander,Интересно, каков же принцип вашего "!MaPro extra indexed pack ver. 1.0"? В каждом *.xpk файле вначале идёт индекс (для zoom 1-7 примерно 85kB), затем идут данные с заголовком по 47 байт, т.е. вы изобрели "велосипед" чисто под нужды вашей программы. Интересно, почему вы решили не использовать БД? Для SAS предлагают использовать БД Беркли - типа всё готово, разберись и юзай. Единственное, продумать индексирование, но в такой БД наверняка должны быть и встроенные механизмы. Лично для меня, пока что действительно легче изобрести что-то своё (только я бы изобретал на основе и подобии кэша GoogleEarth, с некоторыми доработками по индексу), чем освоить Беркли... Останавливает только мысль, что с Беркли успешно работал EarthSlicer и что, возможно, и SAS будет работать с этой БД (хотя опять же, по сути изобретается свой формат кэша - заголовки, принцип индексации и проч.) И ещё, почему-то я уверен, что по быстродействию мой кэш проиграет кэшу на основе БД...


Вы правильно поколупались в моём кэше, именно так там, только зря вы наивно полагаете что индекс обязан быть в начала, он свободно может начинаться 100000000 байта, как и с любого другово. Я не изобратал вилосипед, я просто взял за основу первую мысль которая пришла в голову по индексации кэша, это и стало форматом apk, потом чуть усовершенствовал и получился xpk. Меня всё в кэше устраивает теперь, я даже отказался от усовершенствования до 3 версии, которую недавно разработал, ибо не надо никому такую универсальность и информативность. Раз уж вы смотрели индекс, то полагаю могли бы и понять его примитивную структуру, это очень просто. БД я не стал использовать из соображений скорости, ибо почти все базы данных разрабатывались как универсальный контейнер для информации, мы же имеем дело с вполне вменяемой пирамидальной конструкцией, вполне понятного вида. Тогда почему бы не написать свою быструю и узконаправленную БД - далее кэш. Мой кэш был сделан как индивидуальный накопитель информации, т.е. мне нафиг не надо чтобы какая-нибудь программа поддерживала его, суть в том чтобы сохранить скаченные тайлы и показать их пользователю когда ему надо.

Едиственный недостаток кэша сейчас это скорость проверки наличия тайлов (всреднем всего 100000 тайлов / сек.)
Предположим у меня монитор 1400х1050 пикселов, я хочу посмотреть карту заполнения которая покажет в каждом пикселе наличие тайла, тогда мне надо за раз просмотреть почти 1,5 млн. тайлов, а значит мне придётся ждать 15 секунд. (
Мне бы хотелось чтобы операция занимала менее секунды, чтобы не вызывать неприятного ожидания.
1. Лучший способ ускорить надо запихать всё в оперативку, но ведь индексная структура сейчас у меня занимает 9Гб, хотелось бы поменьше.
2. Мне нет надобности хранить ссылки, мне надо наличие/отсутствие/отсутствие на сервере, значит всего 2 бита на тайл.
3. Нужен быстрый доступ к битам (за малое, очень огранниченное количество операций).

Родилась идея, идея даже была высказана в настолько подробном виде что если какой нибудь заинтересованный программист прочитал, подумал чуть чуть и написал бы уже код имея время на написание. Перед этим идея оформилась на бумаге, теперь реализуется на практике.

Замечу что предпологаемая скорость доступа (4млн.тайлов/сек.) даст желаемый результат (ненавязывать ожидание) и сможет полностью помещаться в памяти (ибо всего 20Мб, может 30Мб для моего текущего состояния кэша).
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: MaPro

Сообщение Alexander » 13 дек 2008, 01:31

zed писал(а):не понял... а где тогда хранится внешний индекс?
Как без пояснения:
Интересно, каков же принцип вашего "!MaPro extra indexed pack ver. 1.0"?
В каждом *.xpk файле вначале идёт индекс (для zoom 1-7 примерно 85kB), затем идут данные с заголовком по 47 байт...


Пока нигде не хранится, пока он только планируется.
Это пояснение было дано после того как я ответил на вопрос о индексном файле.
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: MaPro

Сообщение zed » 13 дек 2008, 02:06

только зря вы наивно полагаете что индекс обязан быть в начала, он свободно может начинаться 100000000 байта, как и с любого другово
Ну не скажите - если размер кэша 1Mb, то индекс не может начаться с "100000000 байта" :) Ваш индекс (тот что в xpk) фиксированного размера? И вообще, вы нигде не описывали свой кэш? Мне интересна его структура, вплоть до байта :)
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: MaPro

Сообщение Alexander » 13 дек 2008, 02:19

zed писал(а):
только зря вы наивно полагаете что индекс обязан быть в начала, он свободно может начинаться 100000000 байта, как и с любого другово
Ну не скажите - если размер кэша 1Mb, то индекс не может начаться с "100000000 байта" :) Ваш индекс (тот что в xpk) фиксированного размера? И вообще, вы нигде не описывали свой кэш? Мне интересна его структура, вплоть до байта :)


Видимо вам не знакомо понятие разряжённых файлов, но не суть. Фиксированного, ибо номеров тайлов в нём фиксированное количество. Говорились общие слова в старом форуме, до байта не расписывал и не буду. Что сложного сочинить файл вида:
1. Заголовок.
2. Индексная структура (ссылки на тайлы).
3. Тайлы.
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: MaPro

Сообщение zed » 13 дек 2008, 02:24

Что сложного сочинить файл вида:
1. Заголовок.
2. Индексная структура (ссылки на тайлы).
3. Тайлы.

Вы правы, сложного ничего нет. Просто было интересно, как это сделано именно в вашей проге, так, для общего развития...
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: MaPro

Сообщение Alexander » 13 дек 2008, 02:33

zed писал(а):
Что сложного сочинить файл вида:
1. Заголовок.
2. Индексная структура (ссылки на тайлы).
3. Тайлы.

Вы правы, сложного ничего нет. Просто было интересно, как это сделано именно в вашей проге, так, для общего развития...


В общем то, то что вы процитировали и есть то что сделано, только тайлы имеют ссылки на предыдущие версии, если они шли заменой, а не добавлением.
Ну и инфа хранится около тайла: тип шифрования данных, дата, ссылка на прежнюю версию, размер данных, хэш, вот вроде и всё.
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: MaPro

Сообщение zed » 13 дек 2008, 14:19

svp писал(а):Беркли -- нереляционная БД. По сути хранит пару [индекс, значение]. Значение -- это сами данные. Индекс лбычно набирается из побайтовой конкатенации значений:
<тип кеша><zoom><x><y>.

Под словом индекс я понимал файл, описывающий БД и позволяющий быстро вычислить расположение данных в базе.
А то, что вы называете "индекс" я называю "заголовок" - некий произвольный набор байт, описывающий сам файл: его имя, зум и т.д. Так вот, если с заголовками все понятно, то вот индексирование продумывать как-то надо, чтобы поиск в БД был очень быстрый (ввиду огромного числа файлов).
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: MaPro

Сообщение svp » 13 дек 2008, 14:46

zed писал(а):А то, что вы называете "индекс" я называю "заголовок" - некий произвольный набор байт, описывающий сам файл: его имя, зум и т.д. Так вот, если с заголовками все понятно, то вот индексирование продумывать как-то надо, чтобы поиск в БД был очень быстрый (ввиду огромного числа файлов).

"чтобы поиск в БД был очень быстрый" в случае с базой беркли не нужно предпринимать ничего. Поиск происходит по индексу.
Вот хорошая статья по беркли http://www.osp.ru/os/2000/11/178318/.
При использовании беркли не нужно делать никаких отдельных индексных баз или структур для быстрого получения нужного тайла по координатам.
Для искомого тайла вычисляется его идентификатор (той же конкатенацией его типа, хума и координат), затем происходит запрос к базе по ключу. Быстрый поиск среди записей записи с нужным нам ключем -- это уже проблема Беркли. Там используются уравновешенные Б-деревья для быстрого поиска нужного ключа в базе.
В том-то и плюс беркли, что она представляет собой готовое решение для наших целей. Не нужно придумывать ни индексную структуру, ни формат хранения, ни механизмы кластеризации большого объёма данных, ни методов восстановления при сбоях. Беркли обладает огромным быстродействием. Не думаю, что при всех её достоинствах возможно смастерить что-то самопальное, что смогло бы конкурировать с Беркли по какому бы то ни было пункту.

PS
Вот копия той статьи, только без разбиения на странички. ИМХО, удобнее.
http://www.inode.ru/articles/database/2006-02-12/296
Аватара пользователя
svp
Советчик
 
Сообщения: 446
ICQ: 204094886
Зарегистрирован: 26 авг 2008, 11:14
Откуда: Белгород
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.

Re: MaPro

Сообщение Alexander » 13 дек 2008, 22:30

svp писал(а):Беркли обладает огромным быстродействием. Не думаю, что при всех её достоинствах возможно смастерить что-то самопальное, что смогло бы конкурировать с Беркли по какому бы то ни было пункту.


Неправда, ибо беркли универсальное решение, а в нашем случае можно упростить алгоритм поиска. Бинарные деревья это не так уж быстро, тем более скорость может существенно отличаться для двух подобранных тайлов. Предлагаемый мной алгоритм индексирования наличия можно изменить так чтобы хранить индекс тайлов в файле, при этом скорость доступа к "смещению тайла" всего 5 шагов целочисленных сравнений. Но дело ваше, можете разбираться с беркли.

Я бы сделал вышеуказанное хранение в одном файле, если бы хоть одна файловая система могла обеспечить честный RandomAccessFile, а то ведь получается если мы запишем 450Гб файл, то скорость доступа к последний байтам гораздо ниже чем к первым, напрягает.
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: MaPro

Сообщение svp » 13 дек 2008, 23:19

Alexander писал(а):Предлагаемый мной алгоритм индексирования наличия можно изменить так чтобы хранить индекс тайлов в файле, при этом скорость доступа к "смещению тайла" всего 5 шагов целочисленных сравнений. Но дело ваше, можете разбираться с Беркли.


Вы подходите к проблеме не с той стороны. На самом деле нет необходимости в таком уж быстром определении наличия каждого тайла в базе. При отрисовке текущего масштаба (а это около 20 тайлов, видимых на экране) хватает даже быстродействия файловой системы, а беркли будет гораздо быстрее.
Вы пытаетесь решить проблему построения карты заполнения экстенсивным методом.
Для этого Вам нужно с огромной скоростью (в некоторых случаях практически для каждого видимого пикселя, а если масштаб построения отличается от текущего более чем на восемь ступеней, то и больше чем для каждого) определять есть ли тайл в базе или нет. И рисуете вы попиксельно. Это в любом случае медленно.
Можно поступать по-другому.
Назовём дочерними все тайлы более высокого масштаба, чем данный и лежащие строго под ним.
Давайте представим, что с каждым тайлом у нас могут хранится дополнительные по два бита на каждый ниже лежащий уровень. i-той парой бит мы будем кодировать следующие состояния: 11 -- все дочерние тайлы i-го уровня (относительно текущего) закачаны; 00 -- ни один тайл i-го уровня не закачан; 01 -- некоторые дочерние тайлы закачаны.
Мы получили пирамидальную структуру, имея которую мы можем не тратить время на проверку наличия каждого тайла i-го уровня в области видимости. Достаточно отрисовать белым квадраты с 11, чёрным с 00 и перейти на более глубокий уровень в случае 01.
Естественно хранить при тайлах эти биты не стоит. Я так сказал для того чтобы было понятнее. Всю эту пирамидальную структуру нужно хранить в виде дерева. Но зачем же запихивать его (это дерево) в файл с кешем? Дерево может с успехом быть использовано отдельно от кеша. Например, если мы хотим отправить товарищу информацию о том, какие тайлы у нас есть, а каких нет. Такие деревья можно объединять, пересекать, вычитать и в качестве маски использовать для копирования и обмена кешем.

А в вашем индивидуальном хранилище предусмотрены какие-то механизмы восстановления данных при сбоях? В беркли предусмотрены. Используя же ваш "быстрый" формат пользователи рискуют потерять всё из-за сбоя во время записи в индексную структуру внутри вашей базы.
Вы прочитали, кстати, статью?
Аватара пользователя
svp
Советчик
 
Сообщения: 446
ICQ: 204094886
Зарегистрирован: 26 авг 2008, 11:14
Откуда: Белгород
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.

Пред.След.

Вернуться в Другие

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron