|
| 1.6, User294 (ok), 18:21, 22/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Странная какая-то фича - и файлов БД становится не один, и проблем с ней есть. На любителя весьма, судя по описанию. При том любитель должен желать много и часто писать в базу (много таких любителей?) и мириться с чуть более тормозным чтением и уймой потенциальных грабель.
| | |
| |
| |
| |
| 4.16, Аноним (-), 02:10, 23/07/2010 [^] [^^] [^^^] [ответить]
| +/– | |
точно genfkey убрали ж в версии 3.6.23, только пока в стабильных ветках дистров более старые версии где он все еще есть
| | |
|
|
|
| |
| 2.18, i (??), 13:04, 23/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
Чуть больше года назад пытался использовать SQLite для хранения данных в ПО на Windows Mobile. К сожалению, все прекрасно работало (простейший тест: создать базу → записать → прочитать → закрыть) на внутренней памяти устройства, а вот если писать на внешнюю SD - валился.
| | |
| |
| 3.19, Veter (??), 13:22, 23/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
У нас работает в продакшене лет 5 на нескольких десятках винмобайловских КПК, ни с одной версией эскулайт проблем не было. А если _у вас_ валился, то однозначно, RTFM.
| | |
|
|
| 1.13, Veter (??), 22:39, 22/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Финансовую поддержку разработчиков SQLite осуществляет
> специально созданный консорциум
На самом деле, это лишь клиенты платной техподдержки эскулайт (кажется, 75 000$ в год все удовольствие стоит без ограничения на число инсталляций; как недавно представители Оракл в рассылке эскулайта писали, это очень выгодно и удобно, так что mush have). "Консорциум" слово красивое, а эскулайт развивается по запросам комьюнити.
> "Ведение WAL-лога существенно повышает надежность хранения данных,
Неправда. Надежность - не повышает, с надежностью в эскулайт и раньше все в порядке было.
> гарантирует атомарность выполнения транзакций
Транзакции всегда атомарны, иначе это не транзакции.
> организовать откат изменений на определенное состояние в прошлом."
На "определенное состояние" откат не делается, по крайней мере, сейчас. Можно только последнюю транзакцию откатить. Теоретически как бы можно было б сделать откат не только последней транзакции, но вместо этого реализованы автоматические чекпойнты и чекпойнты в фоновом потоке. Приложение может заблокировать чекпойнты насовсем, так что журнал будет только расти и можно состряпать утилиту для отката, но ротации журнала нет, так что это будет странный ковыляющий велосипед. Хинт: есть встроенная фича логирования запросов, если нужна история изменений, самое то.
| | |
| 1.17, Кодир (?), 11:40, 23/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Мож я чё в инглише не понимаю, поправьте?
> Advantages include:
> 1. WAL is significantly faster in most scenarios.
> 2. readers do not block writers and a writer does not block readers
и тут же:
> But there are also disadvantages: 6. WAL might be very slightly slower (perhaps 1% or 2% slower) than the traditional rollback-journal approach in applications that do mostly reads and seldom write.
Разве "большинство чтений, изредка запись" не является "most scenarios"?? (биллинг/банкинг не учитывем) Тем более, что теперь ридеры и врайтеры как бы не мешают друг другу. Чудеса...
| | |
| |
| 2.20, Veter (??), 13:32, 23/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
Все верно написано. Для чтения режим WAL чуть медленнее, т.к. надо при чтении заглянуть и в WAL журнал, где могут быть новые версии данных, еще не внесенные в файл БД. Поэтому, если в приложении в основном чтение производится, чтение будет на пару процентов медленнее. При малом числе операций записи (на 1 запрос записи порядка 1000 и выше запросов чтения, почти или полностью read-only БД) и усредненное время всех запросов станет на 1%-2% больше, хотя запись с WAL работает быстрее. Если же запросов записи порядка единиц процентов и более от общего числа обращений к БД (что и обозначено в оригинале как наиболее типичный случай), будет заметен выигрыш от использования WAL.
| | |
|
| 1.21, Knuckles (ok), 12:20, 25/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Клевый проект. Использовал года 2 назад эту БД, остались очень теплые чувства. Все делается очень просто и надежно, хорошая документация. Не без ложки дегтя конечно: на обработке миллионов записей что-то случалось, и запрос не завершался, даже спустя 20-30 минут, что для того проекта было неприемлемо. К счастью, такой сценарий был маловероятен. Наверное мне скажут, что sqlite на таких объемах был не к месту; я даже соглашусь :). Просто была необходима самая маленькая, встроенная в приложение БД.
| | |
| |
| 2.22, Veter (??), 19:25, 26/07/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Наверное мне скажут, что sqlite на таких объемах был не к месту; я даже соглашусь :)
А мы-то не знали, для баз в десятки миллионов и более записей используем ;-) Вот около 500 миллионов записей в модуле полнотекстового поиска проблемка была, а так порядок :-)
| | |
| |
| 3.23, Knuckles (ok), 21:31, 26/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А мы-то не знали, для баз в десятки миллионов и более записей
>используем ;-) Вот около 500 миллионов записей в модуле полнотекстового поиска
>проблемка была, а так порядок :-)
У меня там довольно тяжелый GROUP BY был. С фильтрами и сортировкой. Наверное из-за него все колом вставало.
| | |
|
|
|
