Принцип хранения кеша

[zed]

А интересно, как Вы обошлись без использования dll для доступа к базе: компоненты или самописная "обертка"?

Есть для делфи компонент: DISQLite3 (Delphi Inspiration) - обходится без dll-ок.

Интересно откуда могут быть такие тормоза на рабочем компе?

Если в тестах запись шла сразу на веник, то различная загруженность HDD сторонними процессами могла повлиять на результаты.

[relictus]

Все записи в одной транзакции или для каждой записи своя?

В одной.

Интересно, а насколько отказо-устойчива база SQLite к случайным повреждениям? Cкажем, при переносе кэша на DVD, треть базы случайным образом затёрлась нулями... остальное, неповреждённое мы сможем увидеть/извлечь или всему капец?

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

[zed]

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

Фигово. А я уж только думал кэш делать на SQLite... видимо, придётся думать другой вариант. Надёга должна быть во главе угла.

[Parasite]

Интересно, а насколько отказо-устойчива база SQLite к случайным повреждениям? Cкажем, при переносе кэша на DVD, треть базы случайным образом затёрлась нулями... остальное, неповреждённое мы сможем увидеть/извлечь или всему капец?

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

При массовой закачке областей где НЕТ тайлов (при установленной галочке "сохранять информацию о недоступных тайлах") и последующей попытке просмотра этой "пустой" области из кэша - Ваша программа валится с Memory exception.
Мне так и не удалось НОРМАЛЬНО выкачать и просмотреть 10й уровень для теста (там много дырок в картах) - качается ОК, но даже при переключении потом в 10й уровень (без собственно езды по карте туда-сюда) получаем еррор.
1..8 уровни качаются и просматриваются без проблем.

[Cowa]

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

Фигово. А я уж только думал кэш делать на SQLite... видимо, придётся думать другой вариант. Надёга должна быть во главе угла.

Ну и зря. По-моему, достаточно удачная база. А насчет прочесть частично испорченную базу - backup никто не отменял. А затерев треть базы, уверен, что даже монстр MS SQL тоже обвалится. Есть сомнения?

[zed]

Сомнений нет
Но есть 100% уверенность, что обычный самописный контейнер, когда тайлы просто лепятся в конец друг к другу (кэш GoogleEarth именно по этому принципу построен), при любом повреждении не "обвалится", и неповреждённые тайлы можно юзать без каких бы то нибыло проблем.
Мне казалось, что такая "умная" БД (SQLite) должна бы уметь справляться с проблемой повреждения, или может утилиты какие должны быть, по вытаскиванию целых данных из повреждённых баз. Ведь если перейти на бинарный уровень, то БД - тот же самый контейнер, который хранит данные и никаких принципиальных ограничений по вытаскиванию данных быть не может. Взять к примеру, файловую систему - то же по сути БД, и тем не менее, частичное повреждение оной не означает полную потерю данных. Неповреждённые данные имеют свойство успешно восстанавливаться всякими утилитами.

[Vasya]

А кто мешает почитать умную литературу и написать утилиту, которая будет восстанавливать данные при таком крушении базы ?
Например для ФС народ на это не плохое бабло поднимает.
Мне кажется, что всё это переходит в поиск блох.

[zed]

А кто мешает почитать умную литературу и написать утилиту, которая будет восстанавливать данные при таком крушении базы ?

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

Мне кажется, что всё это переходит в поиск блох.

Ну если вопросы оптимального и надёжного хранения данных, для вас - мелочь, то может быть.
SQLite подходит под определение - оптимальный, но раз нельзя из него восстановить данные, то он явно ненадёжен. А значит в топку его.

[Cowa]

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

Если бы было это так просто и быстро, то все существующие на данный момент базы были ли просто "несокрушимы". Можно заложить в базу и избыточность информации для восстановления и дублировать описание полей таблиц где-нибудь в конце файла-базы (и все это за счет производительности и объема), но все равно найдется несколько байтиков, затерев которые база рухнет.
Так что действительно нужны внешние утилиты, позволяющие восстановить структуру базы (если это возможно) и затем уже смотреть какие данные повреждены. А в простоте, повторюсь - делаем backup. Меня он спасал не один раз.

А значит в топку его.

Категорически против. Мне база очень понравилась.

[Vasya]

Я что-то живя на этом глобусе не один десяток лет пока не видел полностью отказоустойчивой системы.
Думаю, что каждый из нас встречался с таким монстром как Fat12, Fat16 и Fat32 - о какой надёжности можно говорить ? и ничего - сколько лет то проработала.....
Так что может идти другим путём : делиться картами, и случае горя с тобой поделятся ?