SQLite на производственном сервере? [закрыто]

Я давно знаю о SQLite и знаю, что он работает очень быстро, но я никогда не пробовал его на рабочем сервере. Мне так и не удалось найти надежную оценку того, сколько трафика он может обработать, прежде чем потерпеть неудачу.

У кого-нибудь есть номера или статья по этому поводу?

К сожалению, у меня нет никаких данных о возможностях загрузки, но есть несколько комментариев о некоторых факторах, ограничивающих производительность:

• Скорость SQLite зависит от скорости диска, на котором он находится, и от того, происходит ли много операций вставки / обновления (т. Е. Доступа для записи). Блокировка записи ограничена скоростью вращения диска

• Транзакции запускаются по умолчанию, но вы получаете лучшую производительность, если вы начинаете и фиксируете транзакцию. У меня были очень быстрые массовые вставки при обработке транзакции программно

• Если вы обычно только читаете данные, то, по моему опыту, вы получаете хорошую производительность. Таким образом, SQLite можно использовать в качестве системы кэширования для хранения операций чтения с сервера базы данных, в частности удаленных или сложных запросов.

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

• Если вам требуется несколько одновременных записей, то сервер базы данных (например, MySQL, Postgres) вполне может вам помочь

Как сказал Деврим , сайт SQLite утверждает, что около 100 тыс. Пользователей в день должно быть в порядке. Система Trac требует записи, поэтому производительность в этом случае, вероятно, будет ниже

У меня есть несколько моментов, чтобы добавить к этим хорошим ответам.

Текущая версия SQLite имеет WAL (запись в журнал записи), поэтому чтение и запись могут выполняться одновременно. Таким образом, традиционное ограничение одного автора, упомянутое в предыдущих ответах, больше не существует. Я еще не видел WAL на производстве, поэтому не могу комментировать, насколько хорошо он масштабируется.

Используя WAL или нет, если ваша база данных SQLite доступна только для чтения (или пакетно обновляется), и она помещается в ОЗУ (ваша ОС имеет достаточно свободной ОЗУ, чтобы хранить ее в буферах), она может очень хорошо масштабироваться в рабочем веб-приложении. Лично я очень скептически относился к его производительности, масштабируемости и надежности, но теперь, после девяти месяцев работы, он доказал, что отлично работает даже с самыми сложными частями системы .

Sqlite отлично подходит для встраивания в приложения, и именно для этого он предназначен, но он, безусловно, не является «невероятно быстрым». Я использую его для нескольких своих собственных приложений, исключительно для удобства наличия только двух файлов, которые можно скопировать на другую машину, чтобы получить полностью работающее приложение. Тесты на MySQL, использующие ту же структуру, индексы и т. Д., Показывают, что Sqlite значительно медленнее, даже для небольших баз данных. Я ожидаю, что разница в производительности будет расти по мере увеличения размера базы данных, хотя я не могу сказать наверняка, поскольку я использовал ее только с базами данных размером менее 100 МБ.

Я думаю, что sqlite работает быстрее, чем текстовый / XML-файл (вы можете быть удивлены, если попробуете это). И это не поддерживает параллелизм, если вы хотите создать сайт для интранета, где люди регистрируют свое рабочее время или используют тик-тикет, это может хорошо послужить. Кроме этого его следует избегать и заменять на mysql или couchdb.

Веб-сайт sqlite говорит, что 100 тыс. пользователей в день должно быть в порядке, но я в этом сильно сомневаюсь, поскольку простой проект trac сильно зависает при использовании офиса на 10 чел.

Sqlite не является традиционным клиент-серверным приложением БД. По сути, это библиотека, встроенная в другое приложение. Он предназначен для однопользовательских настольных приложений. Вы абсолютно не хотите пытаться использовать его как своего рода отдельную замену MySQL / PostgreSQL / MS-SQL в многопользовательской среде, потому что вся БД заблокирована на запись. Вы будете иметь дело с проблемами конкуренции даже при небольшой нагрузке, которая может снизить производительность.