Использование в Sas.Планета кеша в формате Berkeley

[SergeyKa]

Ну по логике режим явного обьявления транзакции работает в любом случае. А автомат обрамляет вообще все телодвижения.
те для ускорения автомат нужно убрать, а критические части защитить транзакцией.
И еще.. точно беркли не смотрел, но теоретически база накапливается и отдельно должны вестись лог транзакций и индексы.
При разрушении/потере
- файла данных... потери неизбежны
- файла лога восстановима последняя версия
- файла индексов восстановимо - нужна переиндексация
Вот и возникает вопрос: в данной системе так ли уж необходимы транзакции? Мое имхо, что имеет смысл создать инструмент реиндексации, что позволит работать быстее без лога, а в случае сбоя потратить достаточно много времени на восстановление БД.

[SergeyKa]

Berkeley DB поддерживает четыре метода доступа: B+tree, Persistent Queues (Queue), Extended Linear Hashing (Hash) и Fixed- or Variable-length Records (Recno). В методах B+tree и Hash ключи могут иметь произвольную структуру. В методах доступа Queue и Recno каждой записи присваивается номер, который и служит ключом. Во всех методах доступа значение может иметь произвольную структуру. Если программист подставляет собственные функции сравнения или хэширования, Berkeley DB хранит и извлекает значения, не интерпретируя их.

А какой использует САС.планета?
Цитата отсюда http ://www.osp.ru/os/2000/11/178318/

[Tolik]

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

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

[zed]

А какой использует САС.планета?

Btree.

В версии 5.3, кстати появился пятый метод доступа - Heap:

The Heap access method stores records in a heap file. Records are referenced solely by
the page and offset at which they are written. Because records are written in a heap file,
compaction is not necessary when deleting records, which allows for more efficient use
of space than if Btree is in use. The Heap access method is intended for platforms with
constrained disk space, especially if those systems are performing a great many record
creation and deletions.

[SergeyKa]

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

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

Как восстановить битые в беркли незнаю. Но мое имхо, что отсутствие транзакций никак не должно приводить к разрушению БД. Может дело было в другом?

[Tolik]

отсутствие транзакций никак не должно приводить к разрушению БД. Может дело было в другом?

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

[guf]

А что, если использовать в программе не беркли? А например SQLite?
Или БД с клиент-серверной архитектурой? Для примера: выдернуть их XAMPP мобильную версию MySQL и прикрутить ее к программе, с тем, чтоб при каждом старте программа в паре мест меняла ini мускуля и стартовала процесс - безпроблемно совершенно. Запакованый в 7z он весит 11,5 мегов (без баз), распакованый 250. Это как вариант. Как другой вариант - добавить драйвер работы с мускулем.
Просто сдается мне, там проблем с транзакциями и скоростью будет при правильной организации структуры баз в разы меньше. В идеале для каждого слоя свои параметры коннекта прописывать чтоб можно было разные базы юзать, настроить MyISAM и ляпота будет...

[zed]

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

По поводу MySQL - в этом направлении так же идёт разработка (vasketsov ковыряет).

[zed]

Сегодня предпринял некоторые шаги по оптимизации Беркли. Должно заработать немного быстрее.

[DJ VK]

Сегодня предпринял некоторые шаги по оптимизации Беркли. Должно заработать немного быстрее.

пережимать кеш не придется?