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

https://stackoverflow.com/questions/54998

09-06-2019
|

Вопрос

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

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

Решение

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

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

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

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

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

Другие советы

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

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

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

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

Но Sqlite, конечно, сделает это функция в многопользовательской среде, но это не приведет к выполнять что ж.

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

Если вы хотите ускорить работу с 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.Показатель в 100 тысяч просмотров в день это консервативная оценка, а не жесткая верхняя граница.Было продемонстрировано, что 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 (часть, на которую вы ссылались) указывает, что он может использоваться для различных многопользовательских ситуаций.

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

Возможно, это стоит проверить РЕАЛЬНЫЙ SQL-Сервер, который представляет собой сервер базы данных, построенный на SQLite.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow