MaPro

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

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

Re: MaPro

Сообщение zed » 13 дек 2008, 23:39

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

На чём написан MaPro и можно ли использовать ваш алгоритм в сторонних прогах через исходники или dll? На Беркли свет клином не сошёлся, и если вы говорите, что знаете как сделать быстрее/лучше, то можно попробывать и этот вариант...

Я бы сделал вышеуказанное хранение в одном файле, если бы хоть одна файловая система могла обеспечить честный RandomAccessFile, а то ведь получается если мы запишем 450Гб файл, то скорость доступа к последний байтам гораздо ниже чем к первым, напрягает.

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

Re: MaPro

Сообщение zed » 13 дек 2008, 23:50

А в вашем индивидуальном хранилище предусмотрены какие-то механизмы восстановления данных при сбоях?

А смысл? Ну потеряем мы 1 тайл который писали и произошёл сбой - но это ведь мелочь, и нет необходимости в какой-то защите.

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

Re: MaPro

Сообщение svp » 14 дек 2008, 00:02

zed писал(а):А смысл? Ну потеряем мы 1 тайл который писали и произошёл сбой - но это ведь мелочь, и нет необходимости в какой-то защите.

А если ошибка произошла во время записи в индексную структуру? Всё? Крах всего хранилища, или у него там хитрые механизмы резервирования и отката транзакций?

zed писал(а):В принципе, я согласен с Alexander, что Беркли - универсальное решение, и в нём много "лишнего", а вот узкоспециализированные решения были бы лучше (если конечно, эти решения кто-то предоставит, а не придётся всё писать самому с нуля)

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

Re: MaPro

Сообщение Alexander » 14 дек 2008, 00:42

svp писал(а):При отрисовке текущего масштаба (а это около 20 тайлов, видимых на экране) хватает даже быстродействия файловой системы, а беркли будет гораздо быстрее.


Согласен что беркли быстрее файловой системы. (Имхо, ведь в файловой системе используется хэш таблица при поиске, а в беркли бинарные деревья).

svp писал(а):И рисуете вы попиксельно. Это в любом случае медленно.Можно поступать по-другому.


Соласен что попиксельное рисование медленее рисование квадратов, но скорость рисования в оперативке очень высока, а всего то надо записать в буфер 6Мб (для моего монитора), главное не смешивать запись и отрисовку, лучше собрать инфу сделать буфер и наложить его за раз.

svp писал(а):Давайте представим, что с каждым тайлом у нас могут хранится дополнительные по два бита на каждый ниже лежащий уровень. i-той парой бит мы будем кодировать следующие состояния: 11 -- все дочерние тайлы i-го уровня (относительно текущего) закачаны; 00 -- ни один тайл i-го уровня не закачан; 01 -- некоторые дочерние тайлы закачаны.Мы получили пирамидальную структуру, имея которую мы можем не тратить время на проверку наличия каждого тайла i-го уровня в области видимости. Достаточно отрисовать белым квадраты с 11, чёрным с 00 и перейти на более глубокий уровень в случае 01.


Согласен что это решение более эффективно, но оно более трудно в реализации.

svp писал(а):А в вашем индивидуальном хранилище предусмотрены какие-то механизмы восстановления данных при сбоях? В беркли предусмотрены. Используя же ваш "быстрый" формат пользователи рискуют потерять всё из-за сбоя во время записи в индексную структуру внутри вашей базы.


В самом формате этих механизном несколько (в xpk, в apk их почти небыло), но нет реализации самой функции восстановления, это трудоёмкая задача - времени пока нет. Теоритически из повреждённого файла (любой стрепени повреждения) можно извлечь все оставшиеся целыми тайлы. Более того такой вариант как сделан в текущей структуре кэша можно перенести и на однофайловый кэш. Скажу сразу - сейчас если повредить файл кэша вылетит очень неприятное исключение, которое приведёт к заморозке программы (само исключение запишется в лог).

svp писал(а):Но зачем же запихивать его (это дерево) в файл с кешем?


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

svp писал(а):Такие деревья можно объединять, пересекать, вычитать и в качестве маски использовать для копирования и обмена кешем.


Это относится к "2битовым" деревьям.

svp писал(а):Вы прочитали, кстати, статью?


Ещё нет, но читал другие.

zed писал(а):На чём написан MaPro и можно ли использовать ваш алгоритм в сторонних прогах через исходники или dll? На Беркли свет клином не сошёлся, и если вы говорите, что знаете как сделать быстрее/лучше, то можно попробывать и этот вариант...


Написан на дельфи. И поясняйте, пожалуйста, какой именно алгоритм (Индексирования наличия или однофайлового кэша). В любом случае надо ещё реализовать. Я подумаю над dll, но времени пока нет. (Я не знаю как правильно работать с исключениями в dll, если осведомлены поясните, а лучше хорошую статейку).

zed писал(а):А если сделать кэш не в одном, а в нескольких больших файлах определённого размера. Например, весь кэш пишется в один файл, как только размер этого файла достигает определённого заданного лимита (ну, например в 4.3 Гб - для удобного резервирования на DVD) - создавать второй файл и опять его по-тихоньку "наращивать". Так бы было удобнее и скоростью доступа к последним байтам особых проблем не было б.


Острых нет, но проблемы есть. Как резать индекс? Оставить его в первом файле неправильно. Сделать индексы в каждом файле - повысятся накладные расходы в несколько раз (придётся уже не один раз за 5 шагов определять где тайл, а n-раз по 5 шагов). Вынести в отдельный файл - повысятся накладные расходы (в этом случае на указатель на тайл) и чревато ошибками.

zed писал(а):А смысл? Ну потеряем мы 1 тайл который писали и произошёл сбой - но это ведь мелочь, и нет необходимости в какой-то защите.


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

Re: MaPro

Сообщение Alexander » 14 дек 2008, 00:51

svp писал(а):
zed писал(а):А смысл? Ну потеряем мы 1 тайл который писали и произошёл сбой - но это ведь мелочь, и нет необходимости в какой-то защите.

А если ошибка произошла во время записи в индексную структуру? Всё? Крах всего хранилища, или у него там хитрые механизмы резервирования и отката транзакций?

zed писал(а):В принципе, я согласен с Alexander, что Беркли - универсальное решение, и в нём много "лишнего", а вот узкоспециализированные решения были бы лучше (если конечно, эти решения кто-то предоставит, а не придётся всё писать самому с нуля)

Беркли универсальный инструмент. Он именно для таких целей придуман и годами отлажен. Частное решение никогда не будет лучше. Хотя бы из-за недодуманных и недоучтённых проблем. Вы не программист, если поручитесь. что таковых не будет. Ну в крайнем случае безответственный программист=).


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

Re: MaPro

Сообщение Cowa » 14 дек 2008, 02:16

Да, конечно, Berkeley неплохая вещь для хранения данных. Но только что именно вы хотите приобрести имея Berkeley. Базу в одном файле. Удобно. Но не всегда и не всем нужно.
Скорость визуального отображения тайлов на экране. Вряд ли.
Скорость определения наличия тайлов (карта заполнения слоя). Да.
Но только для использования Berkeley нужно еще и писать код. Ведь, цитирую статью, "Berkeley DB по сути представляет собой набор методов доступа и служб", а их оптимизацию применительно для нашего случая придется разрабатывать и описывать. Выбирать в каждом конкретном случае метод доступа к записям, определять размер страниц для оптимизации производительности при блокировании (многопользовательский доступ), да и еще куча всего.
И не всегда узкоспециализированное решение хуже готового универсального. Зачастую даже лучше, т.к. пишется для конкретного случая.
Кстати, svp, кто-то уже давно грозился написать интерфейс (обертку) на Delphi для работы с Berkeley. После этого, написав пару тестовых программ будет понятно что быстрее и в каких случаях.
Cowa
Постигающий Дао
 
Сообщения: 173
Зарегистрирован: 23 авг 2008, 01:46
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: MaPro

Сообщение Alexander » 14 дек 2008, 02:48

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

Re: MaPro

Сообщение zed » 14 дек 2008, 03:05

Написан на дельфи. И поясняйте, пожалуйста, какой именно алгоритм (Индексирования наличия или однофайлового кэша). В любом случае надо ещё реализовать. Я подумаю над dll, но времени пока нет. (Я не знаю как правильно работать с исключениями в dll, если осведомлены поясните, а лучше хорошую статейку).

Интересуют все алгоритмы, что связаны с кэшем: индекс наличия, быстрый поиск в однофайловом кэше...
Если пишите на Делфи, то не обязательно заморачиваться с dll - проще и удобнее будет использовать модуль (типа unit.pas) - ну, это лично мне так.

Alexander писал(а):Кстати забыл упамянуть, если в Berkeley например количество тайлов увеличится в 1000 с небольшим раз, то скорость поиска замедлиться аж в 10 раз в среднем. А я предлагаю индекс скорость работы в котором не зависит от количества тайлов.

Что значит: "увеличится в 1000" это как, с какого значения увеличится? Был 1 файл - всё ОК, добавили в кэш 1000 - скорость в 10 раз упала?

И кстати, про распределённый индекс, во внешнем файле (файлах): viewtopic.php?f=2&t=25#p1394
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: MaPro

Сообщение Alexander » 14 дек 2008, 03:55

zed писал(а):
Написан на дельфи. И поясняйте, пожалуйста, какой именно алгоритм (Индексирования наличия или однофайлового кэша). В любом случае надо ещё реализовать. Я подумаю над dll, но времени пока нет. (Я не знаю как правильно работать с исключениями в dll, если осведомлены поясните, а лучше хорошую статейку).

Интересуют все алгоритмы, что связаны с кэшем: индекс наличия, быстрый поиск в однофайловом кэше...
Если пишите на Делфи, то не обязательно заморачиваться с dll - проще и удобнее будет использовать модуль (типа unit.pas) - ну, это лично мне так.

Alexander писал(а):Кстати забыл упамянуть, если в Berkeley например количество тайлов увеличится в 1000 с небольшим раз, то скорость поиска замедлиться аж в 10 раз в среднем. А я предлагаю индекс скорость работы в котором не зависит от количества тайлов.

Что значит: "увеличится в 1000" это как, с какого значения увеличится? Был 1 файл - всё ОК, добавили в кэш 1000 - скорость в 10 раз упала?

И кстати, про распределённый индекс, во внешнем файле (файлах): viewtopic.php?f=2&t=25#p1394


Во первых кэш сейчас уже состоит из нескольких *.pas, а он связан ещё с несколькими.. Имхо удобочитаемей чем в один файл всё пихать.

Во вторых не файл, а тайл.

Например в базе у вас был 1 тайл, тогда его проверка на наличие это одно сравнение (типа да/нет), если 1024 то не более 10 сравнений (если дерево сбалансированное, иначе в среднем 10), стало у вас 1048576 тайлов в базе то уже в среднем 100 сравнений, а если порядка 536870912 (как у меня), то уже 900 сравнений, если всё дерево разумно прокэшированно в оперативке, то получится порядка 1 млн. проверок/сек. (в лучшем случае; для 536870912 тайлов). Доступ к тайлу возможен тоже с задержкой 1 мкс, но требует большего кэширования. (в лучшем случае; для 536870912 тайлов).

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

Re: MaPro

Сообщение Alexander » 14 дек 2008, 09:59

Alexander писал(а):Например в базе у вас был 1 тайл, тогда его проверка на наличие это одно сравнение (типа да/нет), если 1024 то не более 10 сравнений (если дерево сбалансированное, иначе в среднем 10), стало у вас 1048576 тайлов в базе то уже в среднем 100 сравнений, а если порядка 536870912 (как у меня), то уже 900 сравнений, если всё дерево разумно прокэшированно в оперативке, то получится порядка 1 млн. проверок/сек. (в лучшем случае; для 536870912 тайлов). Доступ к тайлу возможен тоже с задержкой 1 мкс, но требует большего кэширования. (в лучшем случае; для 536870912 тайлов).


Я тут обсчитался с недосыпу.
Вот правильный вариант:
Например в базе у вас был 1 тайл, тогда его проверка на наличие это одно сравнение (типа да/нет), если 1024 то не более 11 сравнений (если дерево сбалансированное, иначе в среднем 10 если почти сбалансированное), стало у вас 1048576 тайлов в базе то уже в среднем 21 сравнений, а если порядка 536870912 (как у меня), то уже 30 сравнений, если всё дерево разумно прокэшированно в оперативке, то получится порядка 30 млн. проверок/сек. (в лучшем случае; для 536870912 тайлов). Доступ к тайлу возможен тоже с задержкой 33 нс, но требует большего кэширования. (в лучшем случае; для 536870912 тайлов).

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

Пред.След.

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

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

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

cron