Используя SQLite в Django в производстве?

Ответ 1

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

По мере роста числа пользователей; простая стратегия блокировки SQLite приведет к усилению конкуренции, и вам нужно будет перенести данные в другую базу данных, такую ​​как MySQL (что может блокировать уровень строк, по крайней мере, с помощью механизма InnoDB) или PostgreSQL (который использует Multiversion concurrency Control). Если вы ожидаете, что вы получите значительное количество пользователей (на уровне, скажем, более 1 запроса в секунду в течение хорошей части дня), вы должны перейти от sqlite; и чем раньше вы это сделаете, тем легче будет.

Ответ 2

Эта проблема в теории баз данных называется concurrency, а SQLite поддерживает ее в версиях Windows > Win98 и в других местах в соответствии с FAQ:

http://www.sqlite.org/faq.html#q5

Мы не знаем, какой другой встроенный механизм СУБД SQL, который поддерживает как много concurrency как SQLite. SQLite позволяет нескольким процессам иметь файл базы данных открывается сразу, а для нескольких процессов читать базы данных сразу. Когда какой-либо процесс хочет писать, он должен заблокировать весь файл базы данных на время его обновления. Но это нормально занимает всего несколько миллисекунд. Другие процессы просто ждут писателя чтобы закончить затем продолжить их бизнес. Другие встроенные SQL двигатели базы данных обычно позволяют только одному процессу подключаться к базы данных сразу.

В принципе, не беспокойтесь о concurrency, любая база данных, заслуживающая ее соли, позаботится просто отлично. Более подробную информацию о том, как SQLite3 управляет этим, можно найти здесь. Вы, как разработчик, а не разработчик баз данных, не должны заботиться об этом, если вы не заинтересованы в внутренней работе.

Ответ 3

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

Любой, кто утверждает, что SQLite хорош или плох для производства, не обсуждая фактический дизайн, не говорит вам многого. SQLite довольно быстро. В некоторых случаях, буквально на порядок быстрее, чем, скажем, Postgres, который появляется как альтернатива для Djangonauts. Как заметил кто-то, он также поддерживает множество concurrency. Это вопрос о том, попадает ли ваше приложение под "некоторые случаи" или нет.

Теперь есть один важный фактор, который нужно учитывать. SQLite - это база данных в процессе. Это действительно важно. Если вы используете что-то вроде gevent, вы можете столкнуться с крайними случаями, когда ваше приложение ломается. Например, попытка выполнить транзакцию, в которой у вас есть контекстный переключатель в середине, может привести к поломке транзакции ужасно. Другими словами, "concurrency" действительно зависит от вашего приложения, потому что SQLite является частью вашего приложения.

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

С другой стороны, процесс in-process означает добавление к нему пользовательских функций и агрегатов довольно тривиально. Я не уверен, что Django ORM делает это более сложным, чем это должно быть, но вы можете придумать неплохие проекты, используя эти возможности.

Ответ 4

Опоздал на вечеринку, но по состоянию на середину 2018 года этот вопрос все еще актуален.

"Клиент" сайта блога - это другой термин, чем "клиент базы данных". В документации SQLite клиент рассматривается как процесс, открывающий файл базы данных. Такой процесс, скажем, приложение django, может обрабатывать множество клиентов веб-приложений ("пользователей") одновременно, и с точки зрения SQLiite он все еще будет одним клиентом.

При выборе SQLite вместо правильной СУБД важно учитывать, состоит ли ваша архитектура из нескольких программных компонентов, подключающихся к базе данных. В таком случае использование SQLite может стать основным узким местом в производительности из-за того, что каждому приложению необходим доступ к одному и тому же файлу БД, возможно, по сети.

Если несколько приложений (клиентов баз данных) не подходят, SQLite - отличный выбор в 99% случаев. Оставшиеся 1% - это приложения, использующие определенные функции БД, приложения под огромной нагрузкой и т.д.

Знай свою архитектуру.

Ответ 5

Не исключено использование Django с Sqlite в качестве базы данных в производственной среде, в первую очередь в зависимости от трафика вашего веб-сайта/веб-приложения и от того, насколько сильно вы ударили по своей базе данных (наряду с тем, какие операции вы над ней выполняете, т.е. читает/пишет/и т.д.). На самом деле, ближе к концу 2019 года я использовал его в нескольких приложениях с небольшим объемом, с ежедневными взаимодействиями менее 5 тыс. (Они встречаются чаще, чем вы думаете).

Проще говоря, для текущего технического состояния в настоящее время Sqlite-3 поддерживает неограниченное число одновременных операций чтения reads (или насколько позволяет ваш компьютер/рабочие), НО только один процесс может записать в него в любой момент времени. Имейте в виду, что хорошо спроектированный запрос/операции с БД будет длиться всего миллисекунды!

Исходя из опыта использования sqlite в качестве единственной базы данных для простой не-рутины (под не-рутиной я подразумеваю, что обычный пользователь не будет использовать это приложение на ежедневной основе круглый год), производственное веб-приложение для сопоставления заданий за рубежом, которое имеет дело с ~ 5000 зарегистрированных учеников (статистика показывает, что число запросов в день постоянно превышает 2 тыс., Что включает посещение базы данных в пик сезона - 40% пишут, 60% читают), у меня не было проблем с таймаутами/проблемами с производительностью.

Это действительно сводится к тому, чтобы быть прагматичным в отношении разработки и URS (спецификации клиента). Если он станет следующим единорогом, всегда можно перенести SQLITE в другую СУБД. Например, см. David d C e Freitas о миграции Быстрый и простой способ миграции SQLite3 на MySQL?

Кроме того, веб-сайт SQLITE использует sqlite db на своем сервере.. см. ниже...

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

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

Пример, который я привел выше для приложения соответствия заданий, которое я создал с использованием sqlite, так как db довольно тяжелый при записи, если вы заметили числа... в среднем 40% - это недолгие операции записи (то есть, отправка форм и т.д.), Но они несут помните, мой объем попадания в БД составляет всего 2 КБ в день в пик сезона.

С другой стороны, если вы понимаете, что ваш sqlite.db вызывает много времени ожидания и плохой пользовательский опыт (408 !!! при отправке формы...), особенно если Django выдает ошибку OperationalError: database is locked: (а затем они должны ввести все заново)... Вы всегда можете увеличить время ожидания в файле settings.py в соответствии с django docs как временное решение, пока вы готовитесь к переносу db.

'OPTIONS': {
# ...
'timeout': 20,
# ...
}

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

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

С Django ORM в большинстве случаев вам не нужно прикасаться к файлам models.py во время миграции на другие поддерживаемые базы данных sql db. Будьте ОЧЕНЬ разумными, хотя Sqlite не поддерживает некоторые более сложные функции и даже поля, чем его старшие собратья MYSQL и POSTGRES.

Ответ 6

SQLite на самом деле не предназначен для производства. Очень легко заставить MySQL или PostgreSQL работать и работать даже в Windows и иметь реальную базу данных.

Реальная проблема заключается в том, что SQLite3 не вставляется в Django, поэтому на вашем сервере может появляться только один просмотр PAGE, см. эту ошибку https://code.djangoproject.com/ticket/12118

Я не использую SQLite3 даже в разработке.