Comments 14
В однопоточном режиме при единой транзакции можно выжать скорость и поболее.
Способ обеспечения ACID в SQLite сильно завязан на FS. Каждый запрос, по сути, отдельная транзакция, для которой бедолага SQLite обязан гарантировать целостность.
Способ обеспечения ACID в SQLite сильно завязан на FS. Каждый запрос, по сути, отдельная транзакция, для которой бедолага SQLite обязан гарантировать целостность.
В однопоточном режиме SQLite показывает около 150000 инсертов в секунду при использовании транзакций (для 1го теста). Что интересно, разницы между SSD и HDD практически нет (154,496 против 152,298).
Если же тестировать одноточный режим по схеме 1 SELECT, 1 UPDATE и 1 INSERT запрос + индексы + общая транзакция, то получаем около 50k операций (но разница уже в пределах 10% для HDD и SDD).
Кстати, на счет ФС. Помимо SSD и HDD надо было сравнить и работу с флешки. Интересно, даст ли преимущество относительно HDD?
Если же тестировать одноточный режим по схеме 1 SELECT, 1 UPDATE и 1 INSERT запрос + индексы + общая транзакция, то получаем около 50k операций (но разница уже в пределах 10% для HDD и SDD).
Кстати, на счет ФС. Помимо SSD и HDD надо было сравнить и работу с флешки. Интересно, даст ли преимущество относительно HDD?
Если сравнивать постгрес и монго можно было бы в настройках поставить fsync = off, интересно что бы вышло…
И ещё, я смотрю вы каждый раз создаёте новое соединение, а postgres это не любит, нужно либо использовать пулинг (pgpool или что по проще) или же переписать тест на client/server и соеденить апач с вашим приложением по scgi/fcgi/wsgi…
И ещё, я смотрю вы каждый раз создаёте новое соединение, а postgres это не любит, нужно либо использовать пулинг (pgpool или что по проще) или же переписать тест на client/server и соеденить апач с вашим приложением по scgi/fcgi/wsgi…
В данном случае разрыв между PostgreSQL и MongoDB почти в 20 раз.
Не думаю, что простым fsync = off это можно было исправить, учитывая использование SSD. А грамотно настраивать PostgreSQL, чтобы он хотя бы сравнился с другими СУБД, я просто не умею.
Что же касается pgpool, то любая СУБД не любит новые соединения. Тот же SQLite в рамках одного соединения дает прирост в 1,5 раза на тех же операциях.
В данном же случае используется самый типовой сценарий использования — каждый запрос открывает свое соединения БД.
Для того, чтобы устроить действительно честное сравнение надо закупить пяток полноценных серверов, под каждую СУБД отдать один и найти грамотных специалистов. Чтобы настройки сделали — максимум скорости, максимум надежности, компромисс.
А потом и устраивать стресс-тесты, в том числе с неожиданными перезагрузками (и считать общий downtime, учитывая «поднятие» «битой» БД).
Вот тогда бы — да, сравнение так сравнение )
Не думаю, что простым fsync = off это можно было исправить, учитывая использование SSD. А грамотно настраивать PostgreSQL, чтобы он хотя бы сравнился с другими СУБД, я просто не умею.
Что же касается pgpool, то любая СУБД не любит новые соединения. Тот же SQLite в рамках одного соединения дает прирост в 1,5 раза на тех же операциях.
В данном же случае используется самый типовой сценарий использования — каждый запрос открывает свое соединения БД.
Для того, чтобы устроить действительно честное сравнение надо закупить пяток полноценных серверов, под каждую СУБД отдать один и найти грамотных специалистов. Чтобы настройки сделали — максимум скорости, максимум надежности, компромисс.
А потом и устраивать стресс-тесты, в том числе с неожиданными перезагрузками (и считать общий downtime, учитывая «поднятие» «битой» БД).
Вот тогда бы — да, сравнение так сравнение )
В данном случае разрыв между PostgreSQL и MongoDB почти в 20 раз.
Не думаю, что простым fsync = off это можно было исправить, учитывая использование SSD.
А мне кажется тут может быть интересные результаты. Во всяком случае для меня они были бы полезны.
Что же касается pgpool, то любая СУБД не любит новые соединения. Тот же SQLite в рамках одного соединения дает прирост в 1,5 раза на тех же операциях.
Но для пострги это особоно плохо.
В данном же случае используется самый типовой сценарий использования — каждый запрос открывает свое соединения БД.
Работаю с Python, Ruby а на php c Symphony и везде f,s,wcgi. Со скриптами которые дёргались каждый раз, сталкивался только году в 2003 и они были на Perl. Не уверен что это прям самый типовой варинат… по этому было бы здорово сделать то же самое но уже без переоткрытия СУБД каждый раз. :)
Для того, чтобы устроить действительно честное сравнение надо закупить пяток полноценных серверов, под каждую СУБД отдать один и найти грамотных специалистов. Чтобы настройки сделали — максимум скорости, максимум надежности, компромисс.
А потом и устраивать стресс-тесты, в том числе с неожиданными перезагрузками (и считать общий downtime, учитывая «поднятие» «битой» БД).
Вот тогда бы — да, сравнение так сравнение )
Ваш вариант вполне хорош, только вы ведь допиливали SQLite (многопоточная работа и т.д.), а остальные взяли как есть. Просто после таких обзоров очень трудно людям втолковать, что всё настроено не было толково. :)
fsync = off не дало прироста для многопоточного режима. 202 операции в секунду сейчас выдает fsync = off и дефолтный режим.
Давайте исключим фактор переподключений.
Тест замеряет время работы в однопточном режиме. 10000 операций, чистая БД. Замер скорости в скрипте, без времени подключения к БД.
Результаты следующие:
PostgreSQL: 1403. Рост в 7 раз. Что подтверждает нелюбовь PostgreSQL к переподключениям.
PostgreSQL (fsync = off): 1766. Рост на четверть относительно дефолтного режима.
SQLite: 938. Странно, раньше 1500 было. Наверное, в тесте была ошибка.
MS SQL: 1993. Рост есть, но незначительный. Где-то на 40% (рост в 1,4 раза).
MySQL: 2514. Рост есть, в 1,7 раза.
MongoDB: 7603. Рост почти в 2,5 раза.
Итого, переподключения больше всего не любит PostgreSQL.
При этом по результатам повторных тестов оказалось, что SQLite к ним равнодушен.
Относительно равнодушен к ним и MS SQL.
Давайте исключим фактор переподключений.
Тест замеряет время работы в однопточном режиме. 10000 операций, чистая БД. Замер скорости в скрипте, без времени подключения к БД.
Результаты следующие:
PostgreSQL: 1403. Рост в 7 раз. Что подтверждает нелюбовь PostgreSQL к переподключениям.
PostgreSQL (fsync = off): 1766. Рост на четверть относительно дефолтного режима.
SQLite: 938. Странно, раньше 1500 было. Наверное, в тесте была ошибка.
MS SQL: 1993. Рост есть, но незначительный. Где-то на 40% (рост в 1,4 раза).
MySQL: 2514. Рост есть, в 1,7 раза.
MongoDB: 7603. Рост почти в 2,5 раза.
Итого, переподключения больше всего не любит PostgreSQL.
При этом по результатам повторных тестов оказалось, что SQLite к ним равнодушен.
Относительно равнодушен к ним и MS SQL.
Большое спасибо! Это в целом то, что я и хотел увидеть.
И как я понял это проводилось на десктопе с windows?
И как я понял это проводилось на десктопе с windows?
И я так понимаю, в итоге для sqlite индексы использовались, а для остальных СУБД нет?
Postgres плохо работает с дисковой подсистемой windows, а вкупе с отсутствием индексов даёт результат хуже MySQL и даже MS SQL, хотя те тесты, что я видел дают приблизительно одинаковые результаты для mysql (в зависимости от движка правда) и postgres.
Это не критика, скорее замечания по поводу особенностей Postgres. Просто он по возможностям стоит близко с MS SQL/Oracle но при этом не затачивался на работу с Windows (его дом это *BSD и linux).
А вот результаты MongoDB меня удивили… я в целом видел, что если не использовать join то postgres сопоставим по скорости с mongo.
Postgres плохо работает с дисковой подсистемой windows, а вкупе с отсутствием индексов даёт результат хуже MySQL и даже MS SQL, хотя те тесты, что я видел дают приблизительно одинаковые результаты для mysql (в зависимости от движка правда) и postgres.
Это не критика, скорее замечания по поводу особенностей Postgres. Просто он по возможностям стоит близко с MS SQL/Oracle но при этом не затачивался на работу с Windows (его дом это *BSD и linux).
А вот результаты MongoDB меня удивили… я в целом видел, что если не использовать join то postgres сопоставим по скорости с mongo.
Нет, индексы во всех СУБД использовались.
Дефолтный индекс по одному полю («i»).
Для MS SQL использовался CLUSTERED индекс.
Особенность данного теста в том, что помимо чтения, я использовал одновременную запись. Причем в рамках одной и той же таблицы.
При этом использовался дефотный режим работы, никакого «грязного» чтения специально не выставлял.
Что же касается PostgreSQL, то его слабые результаты удивили меня самого. Попытался «покопаться» в настройках, но в результате OpenServer отказался стартовать.
Так что к результату PostgreSQL надо относиться с некоторой доли настороженности.
Дефолтный индекс по одному полю («i»).
Для MS SQL использовался CLUSTERED индекс.
Особенность данного теста в том, что помимо чтения, я использовал одновременную запись. Причем в рамках одной и той же таблицы.
При этом использовался дефотный режим работы, никакого «грязного» чтения специально не выставлял.
Что же касается PostgreSQL, то его слабые результаты удивили меня самого. Попытался «покопаться» в настройках, но в результате OpenServer отказался стартовать.
Так что к результату PostgreSQL надо относиться с некоторой доли настороженности.
Sign up to leave a comment.
Тюнинг SQLite для PHP