Насколько масштабируемым является SQLite? [закрытый]
недавно я прочитал этот вопрос о SQLite vs MySQL, и ответ указал, что SQLite не масштабируется хорошо, а официальный сайт sort-of подтверждает это однако.
насколько масштабируемым является SQLite и каковы его верхние пределы?
10 ответов:
вчера я выпустил небольшой сайт* для отслеживания вашего представителя, который использовал общую базу данных SQLite для всех посетителей. К сожалению, даже со скромной нагрузкой, которую он положил на моего хозяина, он бежал довольно медленно. Это связано с тем, что вся база данных была заблокирована каждый раз, когда кто-то просматривал страницу, потому что она содержала обновления/вставки. Вскоре я переключился на MySQL, и хотя у меня не было много времени, чтобы проверить его, он кажется гораздо более масштабируемым, чем SQLite. Я просто помню медленные загрузки страниц и иногда появляется ошибка блокировки базы данных при попытке выполнить запросы из оболочки в sqlite. Тем не менее, я запускаю другой сайт из SQLite просто отлично. Разница в том, что сайт статичен (т. е. я единственный, кто может изменить базу данных), и поэтому он отлично работает для одновременного чтения. Мораль истории: используйте SQLite только для веб-сайтов, где обновления базы данных происходят редко (реже, чем каждая загруженная страница).
edit: Я только что понял, что я возможно, это было несправедливо по отношению к SQLite - я не индексировал столбцы в базе данных SQLite, когда я обслуживал ее с веб-страницы. Это частично вызвало замедление, которое я испытывал. Однако наблюдение за блокировкой базы данных стоит - если у вас есть особенно обременительные обновления, производительность SQLite не будет соответствовать MySQL или Postgres.
другое редактирование: так как я опубликовал это почти 3 месяца назад, у меня была возможность внимательно изучить масштабируемость SQLite, и с несколькими трюки он может быть весьма масштабируемым. Как я уже упоминал в своем первом редактировании, индексы баз данных значительно сокращают время запроса, но это скорее общее наблюдение о базах данных, чем о SQLite. Однако есть еще один трюк, который вы можете использовать для ускорения SQLite:сделки. Всякий раз, когда вам нужно сделать несколько записей базы данных, поместите их в транзакцию. Вместо записи в файл (и блокировки) каждый раз, когда выдается запрос на запись, запись будет выполняться только один раз когда транзакция завершится.
сайт, который я упоминаю, я выпустил в первом абзаце, был переключен обратно на SQLite, и он работает довольно гладко, как только я настроил свой код в нескольких местах.
* веб-сайт больше не доступен
Sqlite масштабируется с точки зрения однопользовательской, у меня есть многогигабайтная база данных, которая работает очень хорошо, и у меня не было особых проблем с ней.
но это - это однопользовательский, так что это зависит от того, о каком масштабировании вы говорите.
в ответ на замечания. Обратите внимание, что нет ничего, что мешает использовать базу данных Sqlite в многопользовательской среде, но каждая транзакция (по сути, каждый оператор SQL, который изменяет базу данных) принимает блокировку на file, что не позволит другим пользователям получить доступ к базе данных на всех.
поэтому, если у вас есть много изменений, внесенных в базу данных, вы, по сути, очень быстро столкнетесь с проблемами масштабирования. Если, с другой стороны, у вас есть много доступа чтения, чем записи, это может быть не так плохо.
но Sqlite будет конечно функции в многопользовательской среде, но это не выполнить что ж.
SQLite управляет sqlite.org веб-сайт и другие, которые имеют много трафика. Они предполагают, что если у вас есть меньше 100к хиты в день, SQLite должен работать нормально. И это было написано до того, как они поставили функцию "Writeahead Logging".
Если вы хотите ускорить работу с SQLite, выполните следующие действия:
- обновление до SQLite 3.7.x
- включить запись вперед ведение журнала
- выполните следующую прагму: "PRAGMA cache_size = Number-of-pages;" размер по умолчанию (количество страниц) составляет 2000 страниц, но если вы увеличите это число, то вы увеличите объем данных, которые работают прямо из памяти.
вы можете взглянуть на мое видео на YouTube под названием"Повышение Производительности SQLite С Writeahead Logging", который показывает, как использовать ведение журнала с опережением записи и демонстрирует 5-кратное улучшение скорости записи.
вы читали этот 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 будет закончен, поскольку только один человек увидит его, если это не общая музыкальная библиотека, где тысячи добавляют или обновляют ее. То MySQL будет использовать.
Так что в теории MySQL масштабируется лучше, чем Sqllite, потому что он может обрабатывать несколько пользователей, но это излишество для одного приложения пользователя.
веб-сайт SQLite (часть, на которую вы ссылались) указывает, что его можно использовать для различных многопользовательских ситуаций.
Я бы сказал, что он может работать совсем немного. По моему опыту, это всегда было очень быстро. Конечно, вам нужно индексировать свои таблицы, и при кодировании против него вам нужно убедиться, что вы используете парамеризованные запросы и тому подобное. В основном то же самое, что вы сделали бы с любой базой данных для повышения производительности.
Это может быть стоит проверить реальный SQL Server, который является сервером баз данных, построенным на SQLite.
Comments