Comments 74
UFO just landed and posted this here
неужто кто-то возлагал на SQLite большие надежды?
он создан не для крупных проектов, а для мелких. там, где не хотелось бы ставить большие библиотеки для работы с нормальными базами. я так думаю.
он создан не для крупных проектов, а для мелких. там, где не хотелось бы ставить большие библиотеки для работы с нормальными базами. я так думаю.
windows? пробуйте *nix
и 'PRAGMA synchronous=OFF' поможет
и 'PRAGMA synchronous=OFF' поможет
абсолютно. SQLite достаточно неоптимально работает с хранилищем под Win/WinCE. под WinCE вообще много проблем. без продолжительного патчинга заставить его работать нормально — невозможно. а контрибуции как-то странно они рассматривают.
Судя по минусам, меня не поняли.
Смотрите ниже тест от юзера ptalus, по которому ясно видно, что sqlite работает в ubuntu 60% от скорости mysql, а в статье (уверен что windows) только 6% от mysql. Имхо тормоза из-за открытия/закрытия файла.
Получается что sqlite (без BEGIN/COMMIT) на ubuntu работает в 10 раз быстрей, чем на windows. А в статье об этом и о платформе не слова.
Смотрите ниже тест от юзера ptalus, по которому ясно видно, что sqlite работает в ubuntu 60% от скорости mysql, а в статье (уверен что windows) только 6% от mysql. Имхо тормоза из-за открытия/закрытия файла.
Получается что sqlite (без BEGIN/COMMIT) на ubuntu работает в 10 раз быстрей, чем на windows. А в статье об этом и о платформе не слова.
странный результат. Запустил ваш тест на своем dev сервере (Ubuntu Server, ядро 2.6, Apache 2, PHP 5.2.6) и получил тот результат на который, как я понял, вы надеялись:
SQLite:
0.0226039886475
0.0238060951233
0.0236310958862
0.015144109726
0.0120120048523
Average time:
0.019439458847
MySQL:
0.0117030143738
0.011342048645
0.0117700099945
0.0126521587372
0.0117499828339
Average time:
0.0118434429169
Количество итераций увеличено до 500:
SQLite
…
Average time:
0.0125000824928
MySql
…
0.0096476111412
SQLite:
0.0226039886475
0.0238060951233
0.0236310958862
0.015144109726
0.0120120048523
Average time:
0.019439458847
MySQL:
0.0117030143738
0.011342048645
0.0117700099945
0.0126521587372
0.0117499828339
Average time:
0.0118434429169
Количество итераций увеличено до 500:
SQLite
…
Average time:
0.0125000824928
MySql
…
0.0096476111412
Весьма показательно, что результаты работы с файловой системой MySQL несильно зависят от ОС (я писал свою базу данных с поддержкой индексирования, которая хранит все данные в 4х файлах, и MySQL везде (и Windows и MacOS X) работает намного шустрее и на вставку и на выборку данных :))
ИМХО нельзя сравнивать SQLite и MySQL чтобы там не говорили — это ведь разные вещи. Наверное более правильным было бы сравнение SQLite c MS Access
Совершенно нелепое сравнение. MS Access по всем тестам отстает. Я прошу прощение за неподтвержденное выкладками заявление, но тесты в нашей компании проводились. На порядок быстрее оказывается SQLite. Да и архитектура совершенно разная. Все разное. Сравнивать SQLite Vs MS Access, имхо, просто нельзя.
RTFM: www.sqlite.org/speed.html
там пишут, что SQLite вынужден открывать/закрывать файл базы данных при выполнении каждой транзакции, т. е. в вашем тесте в каждой итерации. Однако если выполнять все итерации в одной транзакции, то он оказывается быстрее MySQL (все выполняется в Ubuntu Server)
SQLite:
Average time:
0.00223562335968
MySQL:
Average time:
0.00963790082932
там пишут, что SQLite вынужден открывать/закрывать файл базы данных при выполнении каждой транзакции, т. е. в вашем тесте в каждой итерации. Однако если выполнять все итерации в одной транзакции, то он оказывается быстрее MySQL (все выполняется в Ubuntu Server)
SQLite:
Average time:
0.00223562335968
MySQL:
Average time:
0.00963790082932
Спасибо, теперь все ясно)
А для MySQL тесты тоже в одной транзакции выполняются?
Таблицы, наверняка, MyISAM были — какие транзакции?
да
А Беркли и разновидности не тестировали? :) gdbm говорят, самый быстрый :)
Реальный результат на продакшене будет другой. У вас с базой 1 пользователь работает?
Т. к. у sqlite один файл на все таблицы, то при записи будет блокировка ВСЕЙ базы, и во время параллельных запросов на запись отставание sqlite будет очевидным. У MySQL блокировка может быть на уровне таблиц или строк.
Так что ваши тесты не отражают реальных вещей.
Т. к. у sqlite один файл на все таблицы, то при записи будет блокировка ВСЕЙ базы, и во время параллельных запросов на запись отставание sqlite будет очевидным. У MySQL блокировка может быть на уровне таблиц или строк.
Так что ваши тесты не отражают реальных вещей.
подскажите пожалуйста методику, как сымитировать работу нескольких пользователей
Ну хоть кто-то указал на проблемы SQLite при конкурентном доступе.
Только причины не в том, что вся БД в одном файле (в InnoDB несколько БД могут храниться в одном файле). SQLite это встраиваемый сервер, у которого нет выделенного процесса для доступа к файлам БД, поэтому блокировку вожможно осуществлять только на уровне файлов.
Только причины не в том, что вся БД в одном файле (в InnoDB несколько БД могут храниться в одном файле). SQLite это встраиваемый сервер, у которого нет выделенного процесса для доступа к файлам БД, поэтому блокировку вожможно осуществлять только на уровне файлов.
Вы увеены что блокировка на всю базу а не на блоки файла?
А что будет если база состоит из нескольких файлов (например, одна таблица — один файл)?
А что будет если база состоит из нескольких файлов (например, одна таблица — один файл)?
у SQLite на сайте написано черным по английски — писать может ТОЛЬКО ОДИН ПРОЦЕСС
ЗЫ в данной статье вобщемто не было попытки заменить мускул (практически местами полную СУБД) на встраиваемое решение
ЗЫ в данной статье вобщемто не было попытки заменить мускул (практически местами полную СУБД) на встраиваемое решение
UFO just landed and posted this here
нету больше сиквела, годов так с 80х.
есть только эскьюэль.
есть только эскьюэль.
Серьезно?
А в Америке до сих пор говорят «сикуел–сервер», наверное не знают, что отменили ;)
А в Америке до сих пор говорят «сикуел–сервер», наверное не знают, что отменили ;)
сиквела, как торговой марки компании Oracle, нет годов так с 70-х. Оказалось, что это чья-то чужая торговая марка. Но осталось прочтение sql как sequel.
Ролики, пропагандирующие Rails, видели? Я видел. Там сплошь «сикуэл» ;)
Резюмируя вышесказанное в комментариях: SQLite всем хорош при малом количестве пользователей (=одновременных транзакций) и не слишком сложной структуре БД. А в общем очень милая и полезная в своей нише вещь. Когда нужно просто удобно сохранить некоторый структурированный набор данных — самое оно.
мне кажется, что в данном случае выигрыш будет настолько мизерным, что проще MySQL поставить и забыть.
Т. е. для высоких нагрузок MySQL дает большой выигрыш, для малых нагрузок — малый проигрыш.
Т. е. для высоких нагрузок MySQL дает большой выигрыш, для малых нагрузок — малый проигрыш.
На самом деле sqlite обеспечивает и портабельность — не нужно присандаливать большой и прожорливый мускуль.
Согласен.
Но таки есть ситуации, когда поднимать MySQL нецелесообразно. В первую очередь это касается фактически stand-alone приложений, хотя PHP тут уже ни при чём (пока :-)).
В общем, когда есть возможность «MySQL поставить и забыть» — лучше так и сделать. А вот когда её нет — поможет SQLite ))
Но таки есть ситуации, когда поднимать MySQL нецелесообразно. В первую очередь это касается фактически stand-alone приложений, хотя PHP тут уже ни при чём (пока :-)).
В общем, когда есть возможность «MySQL поставить и забыть» — лучше так и сделать. А вот когда её нет — поможет SQLite ))
«нерелятивистская база данных» это пять.
Интересно, что это за вид баз данных такой, «нерелятивистский»? ;)
SQLite плох для большого количества одновременных запросов.
А почему вы решили, что SQLite не подходит для сложных DB схем?
А почему вы решили, что SQLite не подходит для сложных DB схем?
А какой смысл делать цикл запросов внутри транзакции, у вас для задачи «простой счётчик посещений» при каждом посещении в базу пишется 500 строк? :) Конечно, для общей оценки это полезное дело, но в таком случае результат у вас получился не адекватен поставленной задаче, уж извините :)
SQLite хорошь лишь для мелких баз. На более-менее крупных, с десятками тысяч строк совершенно не годиться.
UFO just landed and posted this here
На самом деле sqlite — можно ещё ускорить :) Он достаточно гибок для разных нужд.
Смотри мануал.
Вот пример который я юзал
PRAGMA cache_size = 2000;
PRAGMA default_cache_size = 2000;
PRAGMA encoding = UTF-8;
PRAGMA page_size = 1024;
PRAGMA synchronous = off;
PRAGMA count_changes = off;
PRAGMA temp_store = MEMORY;
Смотри мануал.
Вот пример который я юзал
PRAGMA cache_size = 2000;
PRAGMA default_cache_size = 2000;
PRAGMA encoding = UTF-8;
PRAGMA page_size = 1024;
PRAGMA synchronous = off;
PRAGMA count_changes = off;
PRAGMA temp_store = MEMORY;
Хех… Symbian и Android думаете просто так засунул в себя SQLite =)?
Попробуйте MySQL туда засунуть =) А по скорости тесты вообще не нужны. Где-то нужно одно, а где-то другое… Согласны?
Попробуйте MySQL туда засунуть =) А по скорости тесты вообще не нужны. Где-то нужно одно, а где-то другое… Согласны?
Конечно, но когда у меня молоток и киянка и я не уверен что лучше подойдет в какой-либо ситуации — я пробую постучать одним и другим. Потом пишу про результаты и показываю остальным) И тогда народ решает что кому где надо
К сожалению SQLite действительно хорош только в качестве встраиваемой БД в однопользовательское приложение. В своё время я решил его попробовать на локальном веб-ресурсе. Сейчас это вылилось в то, что даже несмотря на совсем простые запросы, при среднем количестве пользователей в 500-800 в сутки загруженность процессора близка к 100%.
«0.49027895927429»
Зачем столько цифр, если из них меньше половины значащие?
Зачем столько цифр, если из них меньше половины значащие?
Sign up to leave a comment.
Тормозной SQLite? Совсем нет!