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