SQLite в качестве производственной базы данных для сайта с низким трафиком?

SQLite не поддерживает какой-либо параллелизм, поэтому у вас могут возникнуть проблемы с его запуском на рабочем веб-сайте. Если вы ищете «более легкую» базу данных, попробуйте современное хранилище объектных документов, такое как CouchDB.

Во что бы то ни стало, продолжайте разрабатывать SQLite, и вы, вероятно, сможете использовать его на начальном этапе. Если вы обнаружите, что ваше приложение имеет больше пользователей в будущем, вы, тем не менее, захотите перейти на Postgres или MySQL.

Автор SQLite обращается к этому на веб-сайте:

SQLite отлично работает в качестве механизма базы данных для большинства веб-сайтов с низким и средним трафиком (то есть для большинства веб-сайтов). Объем веб-трафика, который может обрабатывать SQLite, зависит от того, насколько интенсивно веб-сайт использует свою базу данных. Вообще говоря, любой сайт с посещаемостью менее 100 000 в день должен нормально работать с SQLite. Цифра в 100 000 посещений в день — это консервативная оценка, а не жесткая верхняя граница. Было продемонстрировано, что SQLite работает с в 10 раз большим объемом трафика.

Веб-сайт SQLite (https://www.sqlite.org/), разумеется, использует сам SQLite, и в качестве На момент написания этой статьи (2015 г.) он обрабатывает от 400 до 500 тысяч HTTP-запросов в день, около 15-20% из которых являются динамическими страницами, касающимися базы данных. Динамический контент использует около 200 операторов SQL на веб-страницу. Эта установка работает на одной виртуальной машине, которая совместно использует физический сервер с 23 другими, но большую часть времени удерживает среднюю нагрузку ниже 0,1.

Итак, я думаю, что если коротко, то дерзайте, и если это не работает для вас, переход на базу данных корпоративного класса в любом случае довольно тривиален. Однако позаботьтесь о своей схеме и спроектируйте базу данных с учетом роста и эффективности.

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

Изменить (2014 г.):

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

Чарльз Лейфер написал сообщение в блоге о возможностях SQLite. Функция WAL (упреждающая запись) и некоторые взвешенные мнения о соответствующих вариантах использования.

Небольшой отрывок с веб-сайта SQLite говорит сам за себя.

• Разделены ли данные от приложения сетью? → выберите клиент/сервер

• Много одновременных авторов? → выберите клиент/сервер

• Большие данные? → выбрать клиент/сервер

• В противном случае → выберите SQLite!

SQLite «просто работает» (пока, конечно, не работает)

Мы часто используем SQLite для внутренних баз данных; Каталог сотрудников, наш календарь событий и другие службы интрасети работают на облегченных базах данных. Было бы излишним запускать эти приложения в масштабе, который мы делаем в «настоящей» базе данных, такой как mySQL. Это особенно верно, если учесть, что они работают вместе с 4 другими виртуальными машинами на одном компьютере среднего уровня.

В какой-то момент у нас был внешний сайт, который месяцами работал на sqlite db, требуя только одной перезагрузки. Очевидно, что это был очень низкий трафик, но он прекрасно справился со своей задачей.

Мы столкнулись с подобным вариантом в среде с полным отсутствием операций записи и выбрали использование SQLite.

См. мой сообщение в блоге на эту тему:

Что ж, основное предположение, которое делает это решение теоретически возможным, заключается в том, что наша база данных SQLite полностью доступна только для чтения. Наш серверный код никогда не должен его менять. Это решит любые проблемы с блокировкой, так как нет блокировки чтения. Мы нигде не смогли найти в Интернете, чтобы кто-нибудь говорил, что есть проблема с высокопроизводительным чтением SQLite, когда нет записи - это может быть возможно!

Я думаю, это будет зависеть в основном от того, какое у вас будет соотношение чтения/записи. Если это в основном чтение из базы данных, вы можете быть в порядке. Многопользовательская запись в SQLite может быть проблемой из-за того, как она блокирует базу данных.

Люди говорят о проблемах параллелизма, но у sqlite есть способ кэшировать входящие запросы и заставлять их ждать некоторое время. Это не тайм-аут немедленно.

Я читал что-то о настройке тайм-аута по умолчанию, которая начинается с нуля, что означает, что время ожидания истекает немедленно, и это чепуха. Может люди не настроили эту настройку?

Зависит от использования сайта. Если большую часть времени вы просто читаете данные, вы можете использовать что угодно для БД и кэшировать данные в приложении для достижения хорошей производительности.

Я использую его на веб-сервере с очень низким трафиком (это геномная база данных), и у меня нет никаких проблем. Но есть только операторы SELECT, запись в БД не требуется.

Чтобы добавить к и без того блестящему ответу: поскольку в этом случае вы работаете с безсерверным решением, вы можете попрощаться с репликацией или любым видом горизонтального масштабирования вашей базы данных, а также с другими дополнительными параметрами. Это также не лучший выбор, если несколько пользователей обновляют один и тот же фрагмент информации. Если бы вы в будущем разделили базу данных, вам пришлось бы перенести данные и перейти на что-то другое. Кроме того, если у вас есть балансировщик нагрузки и задействовано несколько систем, будет сложно поддерживать централизованность данных при использовании sqlite. Это лишь некоторые из причин, почему это не рекомендуется. Он отлично подходит для небольших проектов и отлично подходит для разработки.

Похоже, что с очередями вы также можете избежать многих проблем с параллельной записью в SQLite. Вместо того, чтобы писать непосредственно в sqlite db, вы должны писать в очередь, которая затем, в свою очередь, последовательно записывает в sqlite db в режиме «первый пришел — первый вышел». Не уверен, что ваше приложение достигает того места, где вам это нужно, если его стоит написать или просто перейти к клиент-серверной БД... но мысль.