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


178

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

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

Ответы:


429

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

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

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

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

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


3
MyISAM, «классический» движок базы данных MySQL, имеет те же проблемы с одновременными операциями чтения / записи, что и SQLite. Фактически, он блокирует каждую строку, которой он касается, в операции записи, что делает невозможным масштабирование приложений с интенсивной записью. Тем не менее, он отлично подходит для многих веб-приложений.
Хеннинг

1
Не могли бы вы тогда переписать начало своего ответа? Оценивать производительность БД без соответствующих индексов совершенно несправедливо. Также транзакции сильно влияют на производительность и масштабируемость SQLite.
Корнель

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

1
Можете ли вы поделиться с нами примерно сколько хитов в секунду ваш сайт получает?
NoobOverflow

2
В более новых версиях SQLite есть также возможность записи с опережением записи (WAL), которая может избавить от некоторых трудностей циклов чтения / записи. Вещи меняются.
Лассе В. Карлсен

58

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

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

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

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

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


5
SQLite 3 поддерживает чтение, когда другие пользователи пишут в него.
Аликс Аксель

2
Обратите внимание, что вышеприведенные комментарии устарели, поскольку в новой (er) системе WAL запись и чтение могут выполняться одновременно, что повышает масштабируемость.
Лассе В. Карлсен

Можно ли создавать для экспорта записи на лету в sqlite из любого rdbms, как SQL Server или оракула и т. Д.?
ILoveStackoverflow

29

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

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

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

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


24

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

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


5
Я бы не согласился с «Это включает в себя почти каждый веб-сайт, когда-либо созданный». комментарий. Если сайт загружен, вы правы. Trac, например, использует SQLite по умолчанию и отлично работает из коробки для небольших команд.
Эндрю Бернс

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

3
Что вы определяете как удушье? Исходя из вашего ответа, я предполагаю, что у вас нет большого опыта работы с SQLite. SQLite блокирует весь файл на операциях, так что вы можете столкнуться с задержкой, но в предложенной вами ситуации его практически невозможно заблокировать.
Эндрю Бернс

3
Эндрю, поскольку SQL Lite хорошо работает для небольших групп, не делает его масштабируемым, для масштабируемости требование хорошо масштабируется, то есть оно должно хорошо работать с большими командами. Насколько мне известно, SQL Lite не масштабируется для больших команд / одновременных операций с базами данных, которые превышают довольно низкий порог.
Поп Каталин

5
@Justice. Этот ответ не имеет подтверждающих доказательств того, насколько масштабируем SQLite. Ответ никем намного лучше.
GateKiller

23

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

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


3
Я очень согласен с этим. 99% веб-сайтов могут быть хорошо обработаны с SQLLite, если вы хотите. Но, с другой стороны, 99% веб-трафика идет на самый большой 1% сайтов.
Джангофан

7
Метрика «100 тыс. Посещений в день» - полная чушь. «Хит» обычно определяется как HTTP GET, и веб-сайт с кучей нарезанных изображений может получить более 40 «хитов» за просмотр страницы - ни один из них не касается БД. Даже если в документах есть ошибка при просмотре страницы ==, это все равно вводит в заблуждение. SQLite блокирует всю БД при записи. Хотя он может доблестно обслуживать 100 тыс. Просмотров страниц людей, просто просматривающих записи, он может развалиться в приложении, интенсивно пишущем (электронная торговля, доска объявлений и т. Д.).
jamieb

10

Масштабируемость SQLite будет сильно зависеть от используемых данных и их формата. У меня был сложный опыт работы с очень длинными таблицами (записи GPS, одна запись в секунду). Опыт показал, что SQLite будет замедляться поэтапно, частично из-за постоянной перебалансировки растущих двоичных деревьев, содержащих индексы (и с индексами с метками времени, вы просто знаете, что дерево будет сильно перебалансировано, но это жизненно важно для вашего поиск). Таким образом, в конце концов, около 1 ГБ (очень приблизительный, я знаю), запросы становятся вялыми в моем случае. Ваш пробег будет меняться.

Следует помнить одну вещь, несмотря на все хвастовство, SQLite НЕ предназначен для хранилищ данных. Существуют различные варианты использования, не рекомендуемые для SQLite. Прекрасные люди, стоящие за SQLite, говорят сами за себя:

Другой взгляд на SQLite заключается в следующем: SQLite не предназначен для замены Oracle. Он предназначен для замены fopen ().

И это приводит к основному аргументу (не количественному, извините, но качественному), SQLite не для всех применений, тогда как MySQL может охватывать множество различных применений, даже если не в идеале. Например, вы можете иметь MySQL для хранения файлов cookie Firefox (вместо SQLite), но эта служба должна работать постоянно. С другой стороны, у вас может быть транзакционный веб-сайт, работающий на SQLite (как это делают многие люди) вместо MySQL, но ожидающий много простоев.


1
Вы можете обойти проблему наличия очень больших проиндексированных таблиц, отсекая данные, например одну таблицу в день / неделю. SQLite даже позволяет разбивать таблицы на отдельные файлы базы данных, а затем использовать их ATTACH DATABASEдля создания виртуального подключения к базе данных со всеми таблицами (однако жестко ограничено 62 базами данных).
Аликс Аксель

3

я думаю, что (на цифрах 1) веб-сервер, обслуживающий множество клиентов, появляется на сервере с одним подключением к базе данных, не так ли?

Таким образом, в базе данных нет одновременного доступа, поэтому мы можем сказать, что база данных работает в «однопользовательском режиме». В таких обстоятельствах нет смысла обсуждать многопользовательский доступ, поэтому SQLite работает так же, как и любая другая база данных на сервере.


1
Thx GateKiller, но, пожалуйста, укажите «сайт с низким объемом».
Лед

3

Подумай об этом так. SQL Lite будет блокироваться каждый раз, когда кто-то его использует (SQLite не блокирует чтение). Поэтому, если вы обслуживаете веб-страницу или приложение, в котором одновременно работают несколько пользователей, только одно из них может использовать ваше приложение одновременно с SQLLite. Так что тут есть проблема масштабирования. Если это приложение для одного человека, например, музыкальная библиотека, в которой хранятся сотни названий, рейтингов, информации, использования, воспроизведения и времени воспроизведения, то SQL Lite прекрасно масштабируется, сохраняя тысячи, если не миллионы записей (с поддержкой жесткого диска)

MySQL, с другой стороны, хорошо работает для серверных приложений, где люди будут использовать его одновременно. Он не блокируется и довольно большой по размеру. Таким образом, для вашей музыкальной библиотеки MySql был бы слишком убит, так как ее мог видеть только один человек, ЕСЛИ НЕ это общая музыкальная библиотека, куда тысячи людей добавляют или обновляют ее. Тогда MYSQL будет использовать.

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


5
s / использует его / пишет в него. sqlite не блокируется при чтении.
Грегг Линд

5
ну, ваш ответ может быть легко истолкован. SQLite блокирует только запросы на запись . Мы используем SQLite для более чем 50 ГБ медицинских данных в реляционной форме и обслуживаем сотни одновременных веб-клиентов для просмотра и запроса. Его производительность чтения никогда не хуже, чем в недавнем MySQL.
Берк Д. Демир

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

1

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

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


и использовать транзакции. Это важно для SQLite.
Корнель

-1

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


7
Я не думаю, что какой-либо сайт оправдывает тратить 299 долларов на «РЕАЛЬНЫЙ SQL Server», когда большинство сайтов не получают достаточно трафика, чтобы даже начать выходить за пределы SQLLite.
Джангофан
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.