Сайты для внутреннего использования: Есть ли убедительные аргументы против SQLite?

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

Однако большинство публичных производственных сайтов с высоким трафиком используют более тяжелую базу данных: mySQL, Oracle или postgresql.

Вопросы :

Предполагать:

• Трафик сайта умеренный, и будет иметь место одновременный доступ для чтения / записи к базе данных.
• Мы будем использовать SQLAlchemy с блокировками записи SQLite (хотя этот комментарий заставляет меня немного нервничать)
• База данных будет содержать около 60000 записей
• Структуры данных не требуют расширенных функций в более тяжелых базах данных

Существуют ли когда-либо убедительные аргументы против параллелизма SQLite для веб-сайтов, которые служат внутренними корпоративными инструментами с умеренным трафиком? Если это так, какие условия вызовут проблемы с параллелизмом в SQLite ?

Я ищу известные конкретные причины вместо общего страха / необоснованного указания пальцем.

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

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

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

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

Надев свою шляпу ИТ-директора, я вижу здесь несколько не-gos:

• Риск повреждения данных. Возможно, более восприимчивый, чем реальный, но в конце концов, это БД с нетранзакционными типами файлов, у которой мало возможностей, если есть обращение к плохим записям, кроме вопроса, есть ли у вас последняя резервная копия. Говоря о которых . , ,
• Как мне поддержать эту вещь? Я знаю, что у меня есть хорошая копия. Желательно без отключения приложения.
• Как я могу защитить доступ к БД? В общем, я понимаю, что SQL lite не имеет ничего вне доступа к файловой системе, что является неплохим началом, но не основным, конечным. Особенно для веб-приложений, где вам может потребоваться больше градуированных разрешений, чем администраторам баз данных или ничего

С точки зрения разработчика, я думаю, что важно знать, почему SqlLite используется по умолчанию - потому что он прост и хорошо демонстрирует. Если вы «продаете» платформу новым разработчикам, ключевым моментом является возможность запустить работающее веб-приложение с минимальными усилиями. А того, чтобы встать и правильно настроить сервер базы данных, было бы огромным камнем преткновения, которого следует избегать.