Насколько масштабируем SQLite? [закрыто]

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

Насколько масштабируем SQLite и каковы его верхние пределы?

Вчера я выпустил небольшой сайт ^*для отслеживания вашего представителя, который использовал общую базу данных SQLite для всех посетителей. К сожалению, даже при скромной нагрузке на мой хост он работал довольно медленно. Это потому, что вся база данных была заблокирована каждый раз, когда кто-то просматривал страницу, потому что она содержала обновления / вставки. Вскоре я переключился на MySQL и, хотя у меня не было много времени для его тестирования, он кажется гораздо более масштабируемым, чем SQLite. Я просто помню медленную загрузку страниц и иногда получаю ошибку блокировки базы данных при попытке выполнить запросы из оболочки в sqlite. Тем не менее, я работаю на другом сайте из SQLite просто отлично. Разница в том, что сайт статический (то есть я единственный, кто может изменить базу данных), и поэтому он отлично работает для одновременного чтения. Мораль истории:

редактировать : я только что понял, что, возможно, я не был справедлив по отношению к SQLite - я не индексировал столбцы в базе данных SQLite, когда обслуживал его с веб-страницы. Это частично вызвало замедление, которое я испытывал. Тем не менее, наблюдение за блокировками баз данных стоит на месте - если у вас особенно обременительные обновления, производительность SQLite не будет соответствовать MySQL или Postgres.

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

Сайт, о котором я упомянул в первом параграфе, снова переключился на SQLite, и он работает довольно гладко, когда я настраивал свой код в нескольких местах.

^{* сайт больше не доступен}

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

Но это однопользовательский, так что это зависит от того , какие расширения вы говорите.

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

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

Но Sqlite, конечно, будет работать в многопользовательской среде, но он не будет работать хорошо.

SQLite управляет веб-сайтом sqlite.org и другими, на которых много трафика. Они предполагают, что если у вас менее 100 тыс. Обращений в день, SQLite должен работать нормально. И это было написано до того, как они добавили функцию «Запись в журнал».

Если вы хотите ускорить работу с SQLite, сделайте следующее:

• обновить до SQLite 3.7.x
• Включить запись с опережением
• Запустите следующую прагму: "PRAGMA cache_size = Количество страниц"; Размер по умолчанию (Количество страниц) составляет 2000 страниц, но если вы увеличите это число, то вы увеличите объем данных, выполняющихся прямо из памяти.

Возможно, вы захотите взглянуть на мое видео на YouTube под названием « Повышение производительности SQLite с помощью ведения журнала Writeahead », в котором показано, как использовать ведение журнала с предварительной записью, и продемонстрировано 5-кратное улучшение скорости записи.

Sqlite является рабочим столом или в процессе базе данных. SQL Server, MySQL, Oracle и их братья являются серверами .

Настольные базы данных по своей природе не являются хорошим выбором для любого приложения, которому требуется поддержка одновременного доступа для записи в хранилище данных. Это включает в себя на некотором уровне большинство веб-сайтов, когда-либо созданных. Если вам даже нужно войти в систему для чего-либо, вам, вероятно, нужен доступ на запись в БД.

Вы читали эту документацию по SQLite - http://www.sqlite.org/whentouse.html ?

SQLite обычно отлично работает в качестве движка базы данных для веб-сайтов с низким и средним трафиком (то есть 99,9% всех веб-сайтов). Конечно, объем веб-трафика, который может обрабатывать SQLite, зависит от того, насколько интенсивно веб-сайт использует свою базу данных. Вообще говоря, любой сайт, который получает менее 100 тыс. Посещений в день, должен нормально работать с SQLite. Показатель 100K хитов в день - это консервативная оценка, а не жесткая верхняя граница. Было продемонстрировано, что SQLite работает с 10-кратным объемом трафика.

Масштабируемость 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, потому что он может обрабатывать несколько пользователей, но это излишне для однопользовательского приложения.

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

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

Возможно, стоит проверить REAL SQL Server , который является сервером баз данных, построенным на SQLite.