Насколько масштабируема SQLite? [закрытый]
недавно я прочитал этот вопрос о SQLite против MySQL и ответ указал, что SQLite не масштабируется хорошо и официальный сайт sort-of подтверждает это однако.
насколько масштабируемым является SQLite и каковы его верхние пределы?
10 ответов
вчера я выпустил небольшой сайт* для отслеживания вашего представителя, который использовал общую базу данных SQLite для всех посетителей. К сожалению, даже со скромной нагрузкой, которую он положил на моего хозяина, он бежал довольно медленно. Это связано с тем, что вся база данных была заблокирована каждый раз, когда кто-то просматривал страницу, поскольку она содержала обновления/вставки. Вскоре я переключился на MySQL, и хотя у меня не было много времени, чтобы проверить его, он кажется гораздо более масштабируемым, чем SQLite. Я просто помню медленные загрузки страниц и иногда получение ошибки блокировки базы данных при попытке выполнить запросы из оболочки в sqlite. Тем не менее, я запускаю другой сайт из SQLite просто отлично. Разница в том, что сайт статичен (т. е. я единственный, кто может изменить базу данных), и поэтому он отлично работает для одновременного чтения. Мораль истории: используйте SQLite только для веб-сайтов, где обновления базы данных происходят редко (реже, чем каждая загруженная страница).
редактировать: Я только что понял, что я возможно, это было несправедливо по отношению к SQLite - я не индексировал столбцы в базе данных SQLite, когда обслуживал ее с веб-страницы. Это частично вызвало замедление, которое я испытывал. Однако наблюдение за блокировкой базы данных стоит - если у вас есть особенно обременительные обновления, производительность SQLite не будет соответствовать MySQL или Postgres.
другое редактирование: поскольку я опубликовал это почти 3 месяца назад, у меня была возможность внимательно изучить масштабируемость SQLite и с несколькими трюки могут быть вполне масштабируемыми. Как я упоминал в своем первом редактировании, индексы баз данных значительно сокращают время запроса, но это скорее общее наблюдение о базах данных, чем о SQLite. Однако есть еще один трюк, который вы можете использовать для ускорения SQLite:сделки. Всякий раз, когда вам нужно сделать несколько записей базы данных, поместите их в транзакцию. Вместо записи В (и блокировки) файла каждый раз, когда выдается запрос на запись, запись будет выполняться только один раз когда транзакция завершится.
сайт, который я упомянул, что я выпустил в первом абзаце, был переключен обратно на SQLite, и он работает довольно гладко, как только я настроил свой код в нескольких местах.
* веб-сайт больше не доступен
Sqlite масштабируется с точки зрения одного пользователя, у меня есть база данных с несколькими гигабайтами, которая работает очень хорошо, и у меня не было особых проблем с ней.
но это is однопользовательский, поэтому это зависит от того, о каком масштабировании вы говорите.
в ответ на замечания. Обратите внимание, что нет ничего, что мешает использовать базу данных Sqlite в многопользовательской среде, но каждая транзакция (по сути, каждая инструкция SQL, которая изменяет базу данных) принимает блокировку на , что помешает другим пользователям получить доступ к базе данных на всех.
поэтому, если у вас есть много изменений в базе данных, вы, по сути, очень быстро столкнетесь с проблемами масштабирования. Если, с другой стороны, у вас есть много доступа чтения, чем записи, это может быть не так плохо.
но Sqlite, конечно,функции в многопользовательской среде, но это не выполнить что ж.
SQLite управляет sqlite.org веб-сайт и другие, которые имеют много трафика. Они предполагают, что если у вас есть меньше чем 100k хиты в день, SQLite должен работать нормально. И это было написано до того, как они доставили функцию "Writeahead Logging".
Если вы хотите ускорить работу с SQLite, сделайте следующее:
- обновление до SQLite 3.7.x
- включить запись вперед ведение журнала
- выполните следующую pragma: "PRAGMA cache_size = Number-of-pages;" размер по умолчанию (Number-of-pages) составляет 2000 страниц, но если вы увеличите это число, то вы увеличите объем данных, который работает прямо из памяти.
вы можете взглянуть на мое видео на YouTube под названием"Повышение Производительности SQLite С Writeahead Logging", который показывает, как использовать ведение журнала записи вперед и демонстрирует улучшение скорости 5X для записи.
вы читали этот SQLite docs -http://www.sqlite.org/whentouse.html ?
SQLite обычно будет работать отлично, как СУБД для малых и средних трафик веб-сайтов (то есть, 99,9% всех сайтов). Объем веб-трафика, который может обрабатывать SQLite зависит, конечно, от того, насколько сильно сайт использует свою базу данных. Обычно говоря, любой сайт, который получает меньше чем 100к хитов в сутки должен работать нормально с SQLite. В 100к хиты / дневная цифра является ли консервативная оценка, не трудно верхняя граница. SQLite был продемонстрировали работу с 10 раза такое количество трафика.
масштабируемость SQLite будет сильно зависеть от используемых данных и их формата. У меня был тяжелый опыт работы с очень длинными таблицами (GPS-записи, одна запись в секунду). Опыт показал, что SQLite будет замедляться поэтапно, отчасти из-за постоянного перебалансировки растущих двоичных деревьев, содержащих индексы (и с индексами с отметкой времени, вы просто знаю это дерево будет перебалансироваться много, но это жизненно важно для ваших поисков). Так что в конце концов около 1GB (очень навскидку, я знаю), запросы становятся вялыми в моем случае. Ваш пробег будет меняться.
одна вещь, чтобы помнить, несмотря на все хвастовство, SQLite не предназначен для хранения данных. Существуют различные виды использования не рекомендуется для SQLite. Прекрасные люди за SQLite говорят это сами:
другой способ взглянуть на SQLite таков: SQLite не предназначен для замены Oracle. Он предназначен для замены fopen ().
и это приводит к основной аргумент (не количественный, извините, но качественный), SQLite не для всех применений, тогда как MySQL может охватывать множество различных применений, даже если не идеально. Например, у вас может быть MySQL store Firefox cookies (вместо SQLite), но вам нужна эта служба, работающая все время. С другой стороны, вы можете иметь транзакционный веб-сайт, работающий на SQLite (как и многие люди) вместо MySQL, но ожидать много времени простоя.
Я думаю, что (в числах 1) веб-сервер, обслуживающий hunderts клиентов, появляется на бэкэнде с одним подключением к базе данных, не так ли?
таким образом, в базе данных нет параллельного доступа, поэтому мы можем сказать, что база данных работает в "однопользовательском режиме". Нет смысла дискутировать многопользовательский доступ в таких условиях, поэтому SQLite работает так же, как и любая другая серверная база данных.
подумайте об этом таким образом. SQL Lite будет заблокирован каждый раз, когда кто-то использует его (SQLite не блокируется при чтении). Поэтому, если вы обслуживаете веб-страницу или приложение с несколькими параллельными пользователями, только один может использовать ваше приложение одновременно с SQLLite. Итак, есть проблема масштабирования. Если его приложение для одного человека говорит музыкальную библиотеку, где вы держите сотни названий, рейтингов, информации, использования, воспроизведения, времени воспроизведения, то SQL Lite будет масштабироваться красиво проведение тысячи, если не миллионы записи(жесткий диск готов)
MySQL, с другой стороны, хорошо работает для приложений серверов, где люди будут использовать его одновременно. Он не запирается и довольно большой по размеру. Таким образом, для вашей музыкальной библиотеки MySql будет над kill, поскольку только один человек увидит его, если это не общая музыкальная библиотека, где тысячи добавляют или обновляют ее. Тогда MYSQL будет использоваться.
Так что теоретически MySQL масштабируется лучше, чем Sqllite, потому что он может обрабатывать пользователей mutiple, но overkill для одного приложения пользователя.
веб-сайт SQLite (часть, на которую вы ссылались) указывает, что его можно использовать для различных многопользовательских ситуаций.
Я бы сказал, что он может работать совсем немного. По моему опыту, это всегда было очень быстро. Конечно, вам нужно индексировать таблицы, и при кодировании по ним вам нужно убедиться, что вы используете парамеризованные запросы и тому подобное. В основном то же самое, что вы сделали бы с любой базой данных для повышения производительности.
возможно, стоит проверить реальный SQL Server, который является сервером базы данных, построенным на SQLite.