zed писал(а):Не нужны нам транзакции на локалхосте и откаты с восстановлением
То есть ты считаешь нормальным в случае сбоев проверять и восстанавливать БД какими-то сторонними утилитами, а не автоматически (чего без транзакций и лога не бывает, ну либо без дублирования инфы по нодам распределённой базы)?
Меня так это жутко напрягает.
zed писал(а):потеря даже сотни-другой тайлов, из числа последних прилетевших, не является катастрофой
Восстановление после сбоев нужно же не чтобы все до единого только что прилетевшие тайлы восстановились, а чтобы откатив незавершённые транзакции без помощи рук, база была в согласованном состоянии и была рабочая, а то что было в ней - доступно.
zed писал(а):Вот написать свою БД под конкретную задачу - очень даже интересно
Ну по спецификации тайлового кэша получишь опять же например
BigTable гугловский, там как раз x и y как ключи выступают )).
zed писал(а):И профит должен быть, мне кажется
Профит в смысле скорости работы безусловно будет, базы NoSQL типа "ключ-значение" априори значительно более быстрые, нежели реляционные, тот же
Kyoto например. А вот по надёжности - я не знаю, чтобы было автовосстановление после сбоев, хотя возможно если почитать про транзакционные типа
ravendb например, то там оно будет. А то обычные распределённые просто дублируют данные по нодам в кластере, в случае чего поднимают новый нод.
zed писал(а):если ты прикрутишь SQLite и он взлетит, то может и вообще забью
Безусловно я прикручу SQLite, вот прямо сегодня-завтра и начну заниматься, модель данных будет другая, возможно неверсионная даже сильно кастрированная, как в MBTiles (туда дату отдельным полем в принципе можно добавить, мобильные клиенты не должны отвалиться).
А забивать или нет на NoSQL - дело хозяйское.
В принципе-то интерес же простой: можно ли на надёжном (тут=автовосстанавливаемом) одиночном (тут!=распределённом) движке NoSQL (если таковой вообще существует) получить кэш быстрее и компактнее, чем на SQLite.
Если такого нет или SQLite устроит, то "может и вообще забью".
zed писал(а):народ таки креативит
А в чём там особый креатив? Я вот что-то не углядел.
Так по сути обычное хранилище с 8-байтовым ключом, разве что расписано, какие значения для ключа хранятся, и что есть там magic numbers для возможного автовосстановления после сбоев.
zed писал(а):выравнивание в 512 байт, как на HDD. А в случае плоского файла можно обойтись вообще без такового
И получить например старый добрый кэш GE )))))))))))))
зы. не зря же tar так отлично кроется gz.
Вот, к примеру, про стог сена и иголку в FaceBook: http://www.facebook.com/note.php?note_id=76191543919 - народ таки креативит, а не юзает СУБД на все случаи жизни.
