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

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

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

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

Ответ 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 теперь имеет многопоточный режим и режим записи с опережением записи, что может повлиять на вашу оценку его пригодности для сайтов с низким и средним трафиком.

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Смотрите сообщение в блоге по теме:

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

Если бы это был я, я бы просто использовал MySQL. Мы можем быть слишком драгоценными в этих вещах. У меня был MySQL, работающий на NetGear ReadyNAS, который имеет очень ограниченную память (я думаю, это 256 МБ ОЗУ) и 32 МГц (вы читаете этот правый) процессор. Это нормально. Я работал на низкоуровневом ПК с процессором 200 МГц и небольшой оперативной памятью. Оба случая обслуживают веб-страницы. По общему признанию, не с 20 одновременными пользователями.

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

Ответ 9

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

Ответ 10

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

Ответ 11

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