Исходное сообщение
"Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." Отправлено linux must __RIP__, 09-Июл-13 12:00
>> говорит - что исполнение байт кода - всегда дольше чем просто поиск >> по базе key-> value. > Если обращения к KV store в inner loop - да, разница будет. > Но обычно обращения к БД во внутренних циклах - крайне плохой > тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными. > В остальных случаях накладные расходы будут несущественны. > Не забывайте, что у KV обычно всё атомно плохо с индексацией и > произвольным поиском. Плюсы от возможности вести поиск по связям и наборам > полей могут и перевесить минусы от наличия разборщика запросов. Не везде, > естественно. Плохо с произвольным поиском по ключу?! а индексация там к чему? А о словах secondary key - вы что-то слышали? > Во всяком случае, Subversion уже использует SQLite в клиентской части. Очевидно, осознали > плюсы. Видимо это должно служить большим показателем.. Не подскажете почему? при этом у mysql был bdb сторадж. http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html но я не разу не слышал о SQLite сторадже для MySQL. не подскажете почему? >> Кстати как там с SQLite с поддержкой транзакционного стораджа? > А там иных не бывает... огромная проблема SQLite - необходимость блокирования всего > файла при записи. ЭЭ.. позвольте - если там есть нормальные транзакции - то там не надо блокировать весь файл. Так и запишем - транзакций нету. > Коммиты у SQLite атомарные, поэтому с конзистентностью всё > более-менее. Не хуже, чем у BDB, во всяком случае. у BDB - можно делать комиты в несколько таблиц внутри одной транзакции без необходимости лочить базы. Как видимо это явно "лучше".