GeoCacher

[zed]

Ну и получишь свою реализацию NoSQL, зачем? Собственно СУБД и решает задачу индексирования, кэширования, отката, восстановления после сбоев, параллельного доступа,...

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

В общем велосипед не нужен совсем, всё уже украдено придумано до нас. Главное чтобы была транзакционность и было востановление после сбоев.

Да ну, так совсем не интересно. Вот написать свою БД под конкретную задачу - очень даже интересно. И профит должен быть, мне кажется. Правда я с этим делом не спешу, а если ты прикрутишь SQLite и он взлетит, то может и вообще забью. Просто, почитаешь что-нибудь про хранение данных и мысли так и будоражит Вот, к примеру, про стог сена и иголку в FaceBook: http://www.facebook.com/note.php?note_id=76191543919 - народ таки креативит, а не юзает СУБД на все случаи жизни.

На последовательную запись рассчитан формат tar.

Помимо проблемы с дозаписью, там ещё и выравнивание в 512 байт, как на HDD. А в случае плоского файла можно обойтись вообще без такового и на тайлах q-дерева, террейнах и слоях будет ощутимый профит. Посмотрите на статистику в соседней теме, где я раздаю террейны - типичная картина: число тайлов 1-2 миллиона, размер данных 500Мб, а tar архив выходит гигабайта на 2.

[Shoorick]

Да, недавно читал про идеи в доработке tar, забыл только где.

СУБД для BLOB (больших бинарных объектов) тоже могут быть эффективны.
Свое решение немасштабируемое: понадобится сделать удаление, изменение, еще один тип объекта или индекс - и все, непредусмотрено либо слишком сложно.
Совсем простое решение делал бы отображением файла в виртуальную память. Пусть операционная система берет на себя кэширование. Все равно лучше, чем в ней или в СУБД сочинишь далеко не сразу.

[vasketsov]

Не нужны нам транзакции на локалхосте и откаты с восстановлением

То есть ты считаешь нормальным в случае сбоев проверять и восстанавливать БД какими-то сторонними утилитами, а не автоматически (чего без транзакций и лога не бывает, ну либо без дублирования инфы по нодам распределённой базы)?
Меня так это жутко напрягает.

потеря даже сотни-другой тайлов, из числа последних прилетевших, не является катастрофой

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

Вот написать свою БД под конкретную задачу - очень даже интересно

Ну по спецификации тайлового кэша получишь опять же например BigTable гугловский, там как раз x и y как ключи выступают )).

И профит должен быть, мне кажется

Профит в смысле скорости работы безусловно будет, базы NoSQL типа "ключ-значение" априори значительно более быстрые, нежели реляционные, тот же Kyoto например. А вот по надёжности - я не знаю, чтобы было автовосстановление после сбоев, хотя возможно если почитать про транзакционные типа ravendb например, то там оно будет. А то обычные распределённые просто дублируют данные по нодам в кластере, в случае чего поднимают новый нод.

если ты прикрутишь SQLite и он взлетит, то может и вообще забью

Безусловно я прикручу SQLite, вот прямо сегодня-завтра и начну заниматься, модель данных будет другая, возможно неверсионная даже сильно кастрированная, как в MBTiles (туда дату отдельным полем в принципе можно добавить, мобильные клиенты не должны отвалиться).
А забивать или нет на NoSQL - дело хозяйское.
В принципе-то интерес же простой: можно ли на надёжном (тут=автовосстанавливаемом) одиночном (тут!=распределённом) движке NoSQL (если таковой вообще существует) получить кэш быстрее и компактнее, чем на SQLite.
Если такого нет или SQLite устроит, то "может и вообще забью".

народ таки креативит

А в чём там особый креатив? Я вот что-то не углядел.
Так по сути обычное хранилище с 8-байтовым ключом, разве что расписано, какие значения для ключа хранятся, и что есть там magic numbers для возможного автовосстановления после сбоев.

выравнивание в 512 байт, как на HDD. А в случае плоского файла можно обойтись вообще без такового

И получить например старый добрый кэш GE )))))))))))))
зы. не зря же tar так отлично кроется gz.

[Parasite]

СУБД случайно ещё надо умудриться сломать, тогда как файловый кэш ломается просто по достижению 50 млн тайлов )))

MySQL/MyISAM практически гарантированно валится со всунутыми в нее 100...130m тайлов - причем хорошо так валится, и штатными средствами не поднимается (работа идет, что-то лопатит, а по завершении - "Unable to restore". И это не индексы - их перестройка с нуля ничего не дает). Проверено лично по состоянию\по версии мускула ~2г назад. Специально пробовал 3-4 раза (с таки потерей наработанного), потом отказался от MySQL в плане хранения именно тел тайлов и забыл как страшный сон.

[vasketsov]

MyISAM практически гарантированно валится...Проверено лично по состоянию\по версии мускула ~2г назад

Это именно проблема MyISAM (причём родовая и неустранимая, в том числе в теории). У InnoDB и XtraDB такого быть в теории не должно (ну а есть ли баги на практике - вопрос другой, но по мне так слоны рулят и педалят лучше дельфинов))).

[zed]

То есть ты считаешь нормальным в случае сбоев проверять и восстанавливать БД какими-то сторонними утилитами, а не автоматически

Нет. Я считаю, что для нашего конкретного случая, возможно организовать такую связку БД (с полной поддержкой ACID) и плоских файлов, при которой автоматическое восстановление будет тривиальным и легко реализуемым "на коленке", на тех самых magic numbers с запоминанием оффсета последней успешной записи и без всяких логов и транзакций.

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

[Parasite]

MyISAM практически гарантированно валится...Проверено лично по состоянию\по версии мускула ~2г назад

Это именно проблема MyISAM (причём родовая и неустранимая, в том числе в теории).

Угу. Я знаю. Просто сообщаю, что современная (на момент теста, со с 95% штатных настроек) таки валится - только в путь, причем безо всяких специальных хаканий. А по умолчанию в мускуле конфиги именно под MyISAM.

по мне так слоны рулят и педалят лучше дельфинов))).

На на них и перешел, наимевшись интересного с мускулом по самые тестикулы. И пока что вроде не падало - все весёлые глюки были исключительно по моей вине.
Еще бы с репликацией там нормально разобраться, да все пока лапки не доходят. Судя по мануалам - там тот еще секс. Впрочем, не особо-то и нужно - так, для общего развития...

[OverPaw]

помогите пожалуйста. в чём может быть проблема?

дано:
Windows XP SP3
GoogleEarth.Local 6.0.3.2197
GeoCacher 1.4.3.10

делаю всё по инструкции:
1. в hosts добавил 127.0.0.1 kh.hoogle.com
2. в InternetExplorer прописал прокси 127.0.0.1:8081
3. включаю интернет и запускаю GeoCacher
4. запускаю GE.Local, появляется глобус, значок GeoCacher мигает зелёным
5. закрываю GE.Local, удаляю песочницу
6. отключаю интернет и перевожу GeoCacher в режим "Только из кэша"
7. запускаю GE.Local...

... и получаю ошибку

[zed]

делаю всё по инструкции:

Не по той инструкции делаете (в hosts не нужно ничего писать). Читайте внимательно шапку в топике про GE.Local.
Или, может IE перешёл в автономный режим. Иногда он такое любит. Тогда нужно как-то добиться чтобы он в этот режим не переходил. иначе ничего не заработает.

[xromeo]

Делаю всё как по инструкции. Стартует нормально, запускаю Google Earth, получаю ругательство о невозможности связаться с сервером аутентификации. В логе GUI при этом наблюдаю для подавляющего большинства запросов "Ошибка 404 (I)", строки выделены красным цветом. Соответственно, в итоге ничего не работает.

Версия 1.4.3.10, GoogleEarth последняя с официального сайта (предпочитаю всегда именно её).

Помогите, пожалуйста, разобраться.