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

Question

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

Возможен ли SQLite?

Я знаю, что это не идеальный сценарий производства. Я только спрашиваю, возможно ли, чтобы это было реалистичной возможностью.

Answer 1

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

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

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

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

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

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

---

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

---

Редактировать (2014) :

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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