Тормозной SQLite? Совсем нет!

[@CharnaD]

Я предположил, что SQLite нужен скорее для мелких вещей, типа счетчика посещений. Для тех кто не хочет сервер ставить. Поэтому и тестировал на запись. Сейчас протестирую на чтение и добавлю.

[@i0ngunn3r]

неужели обычные plain text файлы (ну и fopen) настолько менее производительны, чем SQLite? Как раз для таких вещей, как счетчик посещений.

[@gigigi]

ну если 3 юзера в сутки то наверное лучше fopen, а так если несколько открытий параллельно, то это будет уже корявая статистика

[@silentroach]

неужто кто-то возлагал на SQLite большие надежды?
он создан не для крупных проектов, а для мелких. там, где не хотелось бы ставить большие библиотеки для работы с нормальными базами. я так думаю.

[@ni4]

Ну его например Google Chrome пользует. Это крупный проект, или мелкий?

[@ptiss]

и не для крупных, и не для мелких, а для встраиваемых.

[@irishrover]

По сравнению с почти любым сайтом — мелкий.

[@Roxis]

windows? пробуйте *nix
и 'PRAGMA synchronous=OFF' поможет

[@naum]

абсолютно. SQLite достаточно неоптимально работает с хранилищем под Win/WinCE. под WinCE вообще много проблем. без продолжительного патчинга заставить его работать нормально — невозможно. а контрибуции как-то странно они рассматривают.

[@Roxis]

Судя по минусам, меня не поняли.
Смотрите ниже тест от юзера ptalus, по которому ясно видно, что sqlite работает в ubuntu 60% от скорости mysql, а в статье (уверен что windows) только 6% от mysql. Имхо тормоза из-за открытия/закрытия файла.

Получается что sqlite (без BEGIN/COMMIT) на ubuntu работает в 10 раз быстрей, чем на windows. А в статье об этом и о платформе не слова.

[@CharnaD]

я не знаток линукса и не возьмусь утверждать что дело только в ОСи. напишите свое исследование на эту тему) только осторожнее с холиварными заголовками. вообще как я понимаю сравнение винды и линукса тут на хабре больная тема, так же как эппл, гугл и тема.

[@Roxis]

А почему бы Вам просто не указать Вашу платформу и то, что судя по комментариям, на других платформах sqlite работает намного производительней?

[@ptalus]

странный результат. Запустил ваш тест на своем 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

[@CharnaD]

Очень интересно. Провел тесты с 500 итерациями… соотношение такое же, как я указал в статье. Неужели рука Microsoft?

[@naum]

Так оно и есть, точнее говоря, партия в две руки. Посмотрите os_win.h и в целом.

[@youROCK]

Весьма показательно, что результаты работы с файловой системой MySQL несильно зависят от ОС (я писал свою базу данных с поддержкой индексирования, которая хранит все данные в 4х файлах, и MySQL везде (и Windows и MacOS X) работает намного шустрее и на вставку и на выборку данных :))

[@niro]

ИМХО нельзя сравнивать SQLite и MySQL чтобы там не говорили — это ведь разные вещи. Наверное более правильным было бы сравнение SQLite c MS Access

[@naum]

Совершенно нелепое сравнение. MS Access по всем тестам отстает. Я прошу прощение за неподтвержденное выкладками заявление, но тесты в нашей компании проводились. На порядок быстрее оказывается SQLite. Да и архитектура совершенно разная. Все разное. Сравнивать SQLite Vs MS Access, имхо, просто нельзя.

[@niro]

Я не предлагаю сравнивать именно с ним. Я имею ввиду, что надо сравнивать SQLite с соответствуемой БД, но не с MySQL/PostgreSQL/Oracle. ms access случайно подвернулся.

[@ptalus]

RTFM: www.sqlite.org/speed.html
там пишут, что SQLite вынужден открывать/закрывать файл базы данных при выполнении каждой транзакции, т. е. в вашем тесте в каждой итерации. Однако если выполнять все итерации в одной транзакции, то он оказывается быстрее MySQL (все выполняется в Ubuntu Server)
SQLite:
Average time:
0.00223562335968

MySQL:
Average time:
0.00963790082932

[@CharnaD]

Спасибо, теперь все ясно)

[@bat]

А для MySQL тесты тоже в одной транзакции выполняются?

[@galaxy]

Таблицы, наверняка, MyISAM были — какие транзакции?

[@ptalus]

да

[@ptalus]

да тесты MySQL в одной транзакции. ENGINE=MyISAM

[@bat]

MyISAM не поддерживает транзакции. Попробуйте InnoDB. На массовых операциях прирост очень заметен.

[@bat]

+ (уточнение) :)
Имел ввиду прирост по сравнению с InnoDB в режиме autocommit.

P.S.
Хотя про различия между InnoDB и MyISAM ничего сказать не могу.

[@Terehoff]

Основное отличие InnoDB от MyISAM в том, что блокировка в нем идет на уровне записи, а не на уровне таблицы, как в MyISAM. Запись заметно ускоряется. Но вот для чтения MyISAM предпочтительнее.

[@AlexeyK]

А Беркли и разновидности не тестировали? :) gdbm говорят, самый быстрый :)

[@ArtemS]

Реальный результат на продакшене будет другой. У вас с базой 1 пользователь работает?
Т. к. у sqlite один файл на все таблицы, то при записи будет блокировка ВСЕЙ базы, и во время параллельных запросов на запись отставание sqlite будет очевидным. У MySQL блокировка может быть на уровне таблиц или строк.

Так что ваши тесты не отражают реальных вещей.

[@CharnaD]

подскажите пожалуйста методику, как сымитировать работу нескольких пользователей

[@kabachok]

ab -c10 -n100

[@anycolor]

С каких это пор стало хотя бы приблизительно эмулировать работу РЕАЛЬНЫХ пользователей?

[@kabachok]

а где шла реч о РЕАЛЬНЫХ пользователях?

[@anycolor]

Имитация работы нескольких пользователей — это у нас отныне не называется попытка приблизиться к реальным пользователям?:)

[@kabachok]

прочтите первое сообщение нашей ветки, там шла речь об одновременных обращениях к базе данных, мой вариант очень даже подходит, ненадо тут из себя строить умника.

[@bat]

Ну хоть кто-то указал на проблемы SQLite при конкурентном доступе.

Только причины не в том, что вся БД в одном файле (в InnoDB несколько БД могут храниться в одном файле). SQLite это встраиваемый сервер, у которого нет выделенного процесса для доступа к файлам БД, поэтому блокировку вожможно осуществлять только на уровне файлов.

[@Rommidze]

Вы увеены что блокировка на всю базу а не на блоки файла?
А что будет если база состоит из нескольких файлов (например, одна таблица — один файл)?

[@ArtemS]

Разные файлы = разные базы для sqlite. Я не уверен, но разве можно объединять в запросе таблицы из разных файлов (баз)?

[@monsterzz]

Можно.
См. ATTACH в документации к SQLite…

[@bat]

> Вы увеены что блокировка на всю базу а не на блоки файла?

Ситуация: несколько процессов пишут в один файл. Как им синхронизировать свою работу?

[@onk]

у SQLite на сайте написано черным по английски — писать может ТОЛЬКО ОДИН ПРОЦЕСС

ЗЫ в данной статье вобщемто не было попытки заменить мускул (практически местами полную СУБД) на встраиваемое решение

[@silentroach]

нету больше сиквела, годов так с 80х.
есть только эскьюэль.

[@micbsv]

Серьезно?
А в Америке до сих пор говорят «сикуел–сервер», наверное не знают, что отменили ;)

[@silentroach]

en.wikipedia.org/wiki/SQL
читаем pronounce

unofficial не в счет

[@elmar]

сиквела, как торговой марки компании Oracle, нет годов так с 70-х. Оказалось, что это чья-то чужая торговая марка. Но осталось прочтение sql как sequel.

[@vasyathriller]

Ролики, пропагандирующие Rails, видели? Я видел. Там сплошь «сикуэл» ;)

[@silentroach]

ну так говно же. надо говорить правильно, а не так, как захотели какие-то уважаемые люди. которые, возможно, этот sequel еще застали.

[@rubyrabbit]

Резюмируя вышесказанное в комментариях: SQLite всем хорош при малом количестве пользователей (=одновременных транзакций) и не слишком сложной структуре БД. А в общем очень милая и полезная в своей нише вещь. Когда нужно просто удобно сохранить некоторый структурированный набор данных — самое оно.

[@sunnybear]

мне кажется, что в данном случае выигрыш будет настолько мизерным, что проще MySQL поставить и забыть.

Т. е. для высоких нагрузок MySQL дает большой выигрыш, для малых нагрузок — малый проигрыш.

[@d1m]

На самом деле sqlite обеспечивает и портабельность — не нужно присандаливать большой и прожорливый мускуль.

[@rubyrabbit]

Согласен.

Но таки есть ситуации, когда поднимать MySQL нецелесообразно. В первую очередь это касается фактически stand-alone приложений, хотя PHP тут уже ни при чём (пока :-)).

В общем, когда есть возможность «MySQL поставить и забыть» — лучше так и сделать. А вот когда её нет — поможет SQLite ))

[@Uznick]

«нерелятивистская база данных» это пять.

[@kostin]

даешь «реляционную механику» :)

[@Nickname]

Интересно, что это за вид баз данных такой, «нерелятивистский»? ;)

[@FloppyFormator]

Это у которых скорость транзакций намного меньше скорости света в вакууме.

[@Goodkat]

наверное, имелась ввиду низкая скорость :)
релятивистские скорости — это скорости близкие к скорости света

[@Fiery_Ice]

Вряд ли: "… без потери функциональности или скорости...".
В любом случае, Ожегов (автор той статьи) — отжОг. :)

[@MagicWolf]

SQLite плох для большого количества одновременных запросов.

А почему вы решили, что SQLite не подходит для сложных DB схем?

[@Sannis]

А какой смысл делать цикл запросов внутри транзакции, у вас для задачи «простой счётчик посещений» при каждом посещении в базу пишется 500 строк? :) Конечно, для общей оценки это полезное дело, но в таком случае результат у вас получился не адекватен поставленной задаче, уж извините :)

[@romy4]

SQLite хорошь лишь для мелких баз. На более-менее крупных, с десятками тысяч строк совершенно не годиться.

[@CharnaD]

в скором времени попробую опровергнуть или подтвердить ваше утверждение) есть база GeoIP, там порядка 7,7 тысяч записей. Вот и посмотрим где проще, быстрее и лучше)

[@romy4]

7 тысяч — это мало. Тысяч 50 засуньте вместе с varchar :) и разик пробежатся UPDATE table по всем записям с заменой длины строки.

[@diablitozzz]

На самом деле 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;

[@midday]

Хех… Symbian и Android думаете просто так засунул в себя SQLite =)?

Попробуйте MySQL туда засунуть =) А по скорости тесты вообще не нужны. Где-то нужно одно, а где-то другое… Согласны?

[@CharnaD]

Конечно, но когда у меня молоток и киянка и я не уверен что лучше подойдет в какой-либо ситуации — я пробую постучать одним и другим. Потом пишу про результаты и показываю остальным) И тогда народ решает что кому где надо

[@midday]

Ну за топик спасибо. Всегда интересны такие статьи…
Так вот… Давайте доведем статью до конца. Многие высказались =) подведи итоги?

[@CharnaD]

Изначально я хотел узнать почему SQLite так тупит на запись. Узнал. Теперь вывод я считаю в том, чтобы переубедить тех, кто отказывался от SQLite потому что он протестировал так же, как и я сначала и отказался от него.

[@Rukuki_Ake]

К сожалению SQLite действительно хорош только в качестве встраиваемой БД в однопользовательское приложение. В своё время я решил его попробовать на локальном веб-ресурсе. Сейчас это вылилось в то, что даже несмотря на совсем простые запросы, при среднем количестве пользователей в 500-800 в сутки загруженность процессора близка к 100%.

[@alexbooter]

«0.49027895927429»

Зачем столько цифр, если из них меньше половины значащие?