Пользователь
0,0
рейтинг
12 октября 2008 в 14:11

Разработка → Тормозной SQLite? Совсем нет!

Как-то заинтересовавшись SQLite я решил проверить, а не будет ли оно быстрее MySQL, или хотя бы равным по скорости.
Я исходил из того, что SQLite скорее всего будет удобна для мелких таблиц, типа простых счетчиков посещений.
Поэтому провел тесты следующим способом: я пять раз мерял время по 100 циклов обновления записи в базе и пять раз по 100 чтения.
Код тут.

Итак, в статье убеждали: "В последнее время, вы, возможно, слышали о новом расширении для PHP: SQLite. Есть много причин, по которым SQLite может показаться лучшим достижением с тех пор, как научились резать хлеб. SQLite предлагает добротный SQL интерфейс к нерелятивистской базе данных и создаёт элегантную альтернативу громоздким интерфейсам других баз данных без потери функциональности или скорости, как можно было бы ожидать.".

Смотрим что же получилось по тестам…
     SQLite                    MySQL
		Запись
0.45911908149719	0.031841039657593
0.46412396430969	0.031555891036987
0.49027895927429	0.029323101043701
0.46884489059448	0.029382944107056
0.50253915786743	0.028644800186157
		Среднее
0.47698121070862	0.030149555206299

		Чтение
0.026177883148193	0.060520172119141
0.026360988616943	0.059216022491455
0.026273012161255	0.062637090682983
0.026113986968994	0.062775135040283
0.026944160461426	0.062674045562744
		Среднее
0.026374006271362	0.061564493179321


Удивительный провал на запись и преимущество в чтении. Однако спасибо ptalus, который пролил свет на это дело. В мануале написано, что для каждой записи файл открывается-закрывается, что и влечет за собой такую тормознутость, однако стоит добавить

sqlite_query($dbhandle, 'BEGIN;');
sqlite_query($dbhandle, 'COMMIT;');

вокруг запроса и время записи просто магически меняется.

Запись:
0.014724016189575
0.014418125152588
0.015676975250244
0.014610052108765
0.014219999313354
Среднее:
0.014729833602905

ЗЫ: тесты на время провожу в первый раз, подскажите, если где лоханулся.
CharnaD @CharnaD
карма
65,9
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (74)

  • +1
    AFAIK на запись он явно медленей будет т. к. весьма «оригинально» хранит данные. Но пробовали тестировать на выборку?
    • +1
      Я предположил, что SQLite нужен скорее для мелких вещей, типа счетчика посещений. Для тех кто не хочет сервер ставить. Поэтому и тестировал на запись. Сейчас протестирую на чтение и добавлю.
      • 0
        неужели обычные plain text файлы (ну и fopen) настолько менее производительны, чем SQLite? Как раз для таких вещей, как счетчик посещений.
        • 0
          ну если 3 юзера в сутки то наверное лучше fopen, а так если несколько открытий параллельно, то это будет уже корявая статистика
  • +2
    неужто кто-то возлагал на SQLite большие надежды?
    он создан не для крупных проектов, а для мелких. там, где не хотелось бы ставить большие библиотеки для работы с нормальными базами. я так думаю.
    • +3
      Ну его например Google Chrome пользует. Это крупный проект, или мелкий?
      • +3
        и не для крупных, и не для мелких, а для встраиваемых.
      • –4
        По сравнению с почти любым сайтом — мелкий.
  • 0
    windows? пробуйте *nix
    и 'PRAGMA synchronous=OFF' поможет
    • +1
      абсолютно. SQLite достаточно неоптимально работает с хранилищем под Win/WinCE. под WinCE вообще много проблем. без продолжительного патчинга заставить его работать нормально — невозможно. а контрибуции как-то странно они рассматривают.
    • +1
      Судя по минусам, меня не поняли.
      Смотрите ниже тест от юзера ptalus, по которому ясно видно, что sqlite работает в ubuntu 60% от скорости mysql, а в статье (уверен что windows) только 6% от mysql. Имхо тормоза из-за открытия/закрытия файла.

      Получается что sqlite (без BEGIN/COMMIT) на ubuntu работает в 10 раз быстрей, чем на windows. А в статье об этом и о платформе не слова.
      • 0
        я не знаток линукса и не возьмусь утверждать что дело только в ОСи. напишите свое исследование на эту тему) только осторожнее с холиварными заголовками. вообще как я понимаю сравнение винды и линукса тут на хабре больная тема, так же как эппл, гугл и тема.
        • 0
          А почему бы Вам просто не указать Вашу платформу и то, что судя по комментариям, на других платформах sqlite работает намного производительней?
  • +4
    странный результат. Запустил ваш тест на своем 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
    • 0
      Очень интересно. Провел тесты с 500 итерациями… соотношение такое же, как я указал в статье. Неужели рука Microsoft?
      • 0
        Так оно и есть, точнее говоря, партия в две руки. Посмотрите os_win.h и в целом.
  • +2
    Весьма показательно, что результаты работы с файловой системой MySQL несильно зависят от ОС (я писал свою базу данных с поддержкой индексирования, которая хранит все данные в 4х файлах, и MySQL везде (и Windows и MacOS X) работает намного шустрее и на вставку и на выборку данных :))
  • +2
    ИМХО нельзя сравнивать SQLite и MySQL чтобы там не говорили — это ведь разные вещи. Наверное более правильным было бы сравнение SQLite c MS Access
    • +2
      Совершенно нелепое сравнение. MS Access по всем тестам отстает. Я прошу прощение за неподтвержденное выкладками заявление, но тесты в нашей компании проводились. На порядок быстрее оказывается SQLite. Да и архитектура совершенно разная. Все разное. Сравнивать SQLite Vs MS Access, имхо, просто нельзя.
      • 0
        Я не предлагаю сравнивать именно с ним. Я имею ввиду, что надо сравнивать SQLite с соответствуемой БД, но не с MySQL/PostgreSQL/Oracle. ms access случайно подвернулся.
  • +9
    RTFM: www.sqlite.org/speed.html
    там пишут, что SQLite вынужден открывать/закрывать файл базы данных при выполнении каждой транзакции, т. е. в вашем тесте в каждой итерации. Однако если выполнять все итерации в одной транзакции, то он оказывается быстрее MySQL (все выполняется в Ubuntu Server)
    SQLite:
    Average time:
    0.00223562335968

    MySQL:
    Average time:
    0.00963790082932
    • 0
      Спасибо, теперь все ясно)
    • +4
      А для MySQL тесты тоже в одной транзакции выполняются?
      • 0
        Таблицы, наверняка, MyISAM были — какие транзакции?
      • 0
        да
        • –1
          да тесты MySQL в одной транзакции. ENGINE=MyISAM
          • 0
            MyISAM не поддерживает транзакции. Попробуйте InnoDB. На массовых операциях прирост очень заметен.
            • 0
              + (уточнение) :)
              Имел ввиду прирост по сравнению с InnoDB в режиме autocommit.

              P.S.
              Хотя про различия между InnoDB и MyISAM ничего сказать не могу.
              • 0
                Основное отличие InnoDB от MyISAM в том, что блокировка в нем идет на уровне записи, а не на уровне таблицы, как в MyISAM. Запись заметно ускоряется. Но вот для чтения MyISAM предпочтительнее.
  • 0
    А Беркли и разновидности не тестировали? :) gdbm говорят, самый быстрый :)
  • +7
    Реальный результат на продакшене будет другой. У вас с базой 1 пользователь работает?
    Т. к. у sqlite один файл на все таблицы, то при записи будет блокировка ВСЕЙ базы, и во время параллельных запросов на запись отставание sqlite будет очевидным. У MySQL блокировка может быть на уровне таблиц или строк.

    Так что ваши тесты не отражают реальных вещей.
    • 0
      подскажите пожалуйста методику, как сымитировать работу нескольких пользователей
      • +3
        ab -c10 -n100
        • 0
          С каких это пор стало хотя бы приблизительно эмулировать работу РЕАЛЬНЫХ пользователей?
          • 0
            а где шла реч о РЕАЛЬНЫХ пользователях?
            • 0
              Имитация работы нескольких пользователей — это у нас отныне не называется попытка приблизиться к реальным пользователям?:)
              • +5
                прочтите первое сообщение нашей ветки, там шла речь об одновременных обращениях к базе данных, мой вариант очень даже подходит, ненадо тут из себя строить умника.
    • 0
      Ну хоть кто-то указал на проблемы SQLite при конкурентном доступе.

      Только причины не в том, что вся БД в одном файле (в InnoDB несколько БД могут храниться в одном файле). SQLite это встраиваемый сервер, у которого нет выделенного процесса для доступа к файлам БД, поэтому блокировку вожможно осуществлять только на уровне файлов.
    • +1
      Вы увеены что блокировка на всю базу а не на блоки файла?
      А что будет если база состоит из нескольких файлов (например, одна таблица — один файл)?
      • 0
        Разные файлы = разные базы для sqlite. Я не уверен, но разве можно объединять в запросе таблицы из разных файлов (баз)?
        • 0
          Можно.
          См. ATTACH в документации к SQLite…
      • 0
        > Вы увеены что блокировка на всю базу а не на блоки файла?

        Ситуация: несколько процессов пишут в один файл. Как им синхронизировать свою работу?
    • 0
      у SQLite на сайте написано черным по английски — писать может ТОЛЬКО ОДИН ПРОЦЕСС

      ЗЫ в данной статье вобщемто не было попытки заменить мускул (практически местами полную СУБД) на встраиваемое решение
  • НЛО прилетело и опубликовало эту надпись здесь
    • –3
      нету больше сиквела, годов так с 80х.
      есть только эскьюэль.
      • +1
        Серьезно?
        А в Америке до сих пор говорят «сикуел–сервер», наверное не знают, что отменили ;)
      • 0
        сиквела, как торговой марки компании Oracle, нет годов так с 70-х. Оказалось, что это чья-то чужая торговая марка. Но осталось прочтение sql как sequel.
      • –1
        Ролики, пропагандирующие Rails, видели? Я видел. Там сплошь «сикуэл» ;)
        • –2
          ну так говно же. надо говорить правильно, а не так, как захотели какие-то уважаемые люди. которые, возможно, этот sequel еще застали.
  • +2
    Резюмируя вышесказанное в комментариях: SQLite всем хорош при малом количестве пользователей (=одновременных транзакций) и не слишком сложной структуре БД. А в общем очень милая и полезная в своей нише вещь. Когда нужно просто удобно сохранить некоторый структурированный набор данных — самое оно.
    • +3
      мне кажется, что в данном случае выигрыш будет настолько мизерным, что проще MySQL поставить и забыть.

      Т. е. для высоких нагрузок MySQL дает большой выигрыш, для малых нагрузок — малый проигрыш.
      • +3
        На самом деле sqlite обеспечивает и портабельность — не нужно присандаливать большой и прожорливый мускуль.
      • +1
        Согласен.

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

        В общем, когда есть возможность «MySQL поставить и забыть» — лучше так и сделать. А вот когда её нет — поможет SQLite ))
  • +22
    «нерелятивистская база данных» это пять.
    • +9
      даешь «реляционную механику» :)
  • +6
    Интересно, что это за вид баз данных такой, «нерелятивистский»? ;)
    • +16
      Это у которых скорость транзакций намного меньше скорости света в вакууме.
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      наверное, имелась ввиду низкая скорость :)
      релятивистские скорости — это скорости близкие к скорости света
      • 0
        Вряд ли: "… без потери функциональности или скорости...".
        В любом случае, Ожегов (автор той статьи) — отжОг. :)
  • 0
    SQLite плох для большого количества одновременных запросов.

    А почему вы решили, что SQLite не подходит для сложных DB схем?
  • 0
    А какой смысл делать цикл запросов внутри транзакции, у вас для задачи «простой счётчик посещений» при каждом посещении в базу пишется 500 строк? :) Конечно, для общей оценки это полезное дело, но в таком случае результат у вас получился не адекватен поставленной задаче, уж извините :)
  • 0
    SQLite хорошь лишь для мелких баз. На более-менее крупных, с десятками тысяч строк совершенно не годиться.
    • 0
      в скором времени попробую опровергнуть или подтвердить ваше утверждение) есть база GeoIP, там порядка 7,7 тысяч записей. Вот и посмотрим где проще, быстрее и лучше)
      • 0
        7 тысяч — это мало. Тысяч 50 засуньте вместе с varchar :) и разик пробежатся UPDATE table по всем записям с заменой длины строки.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    На самом деле 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;
  • 0
    Хех… Symbian и Android думаете просто так засунул в себя SQLite =)?

    Попробуйте MySQL туда засунуть =) А по скорости тесты вообще не нужны. Где-то нужно одно, а где-то другое… Согласны?
    • 0
      Конечно, но когда у меня молоток и киянка и я не уверен что лучше подойдет в какой-либо ситуации — я пробую постучать одним и другим. Потом пишу про результаты и показываю остальным) И тогда народ решает что кому где надо
      • 0
        Ну за топик спасибо. Всегда интересны такие статьи…
        Так вот… Давайте доведем статью до конца. Многие высказались =) подведи итоги?
        • 0
          Изначально я хотел узнать почему SQLite так тупит на запись. Узнал. Теперь вывод я считаю в том, чтобы переубедить тех, кто отказывался от SQLite потому что он протестировал так же, как и я сначала и отказался от него.
  • 0
    К сожалению SQLite действительно хорош только в качестве встраиваемой БД в однопользовательское приложение. В своё время я решил его попробовать на локальном веб-ресурсе. Сейчас это вылилось в то, что даже несмотря на совсем простые запросы, при среднем количестве пользователей в 500-800 в сутки загруженность процессора близка к 100%.
  • +2
    «0.49027895927429»

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.