Вопросы | sqlite

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

Вопрос

GateKiller | 40496 просмотров | рейтинг: 7

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



Ответы

Lasse Vågsæther Karlsen

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


Kyle Cronin

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


Joel Coehoorn

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


Sam

+ 2 -
Думай об этом так. SQL Lite будет блокироваться каждый раз, когда кто-то его использует (SQLite не блокирует чтение). Поэтому, если вы обслуживаете веб-страницу или приложение, в котором одновременно работают несколько пользователей, только одно из них может использовать ваше приложение одновременно с SQLLite. Так что тут есть проблема масштабирования. Если это приложение для одного человека, например, музыкальная библиотека, в которой хранятся сотни названий, рейтингов, информации, использования, воспроизведения и времени воспроизведения, то SQL Lite будет прекрасно масштабироваться, сохраняя тысячи, если не миллионы записей (с поддержкой жесткого диска) MySQL, с другой стороны, хорошо работает для серверных приложений, где люди будут использовать его одновременно. Он не блокируется и довольно большой по размеру. Таким образом, для вашей музыкальной библиотеки MySql был бы слишком убит, так как ее мог видеть только один человек, ЕСЛИ НЕ это общая музыкальная библиотека, куда тысячи людей добавляют или обновляют ее. Тогда MYSQL будет использовать. Таким образом, теоретически MySQL масштабируется лучше, чем Sqllite, потому что он может обрабатывать несколько пользователей, но это излишне для однопользовательского приложения.


Lasse Vågsæther Karlsen

+ 23 -
Вы читали эту документацию по SQLite - http://www.sqlite.org/whentouse.html?
  SQLite обычно будет отлично работать как   ядро базы данных для низкого и среднего   трафик веб-сайтов (то есть,   99,9% всех сайтов). Объем веб-трафика, который может обрабатывать SQLite   зависит, конечно, от того, насколько сильно   Сайт использует свою базу данных. В общем   говоря, любой сайт, который получает меньше   чем 100K хитов / день должен работать нормально   с SQLite. 100 000 хитов в день   это консервативная оценка, а не жесткая   верхняя граница. SQLite был   продемонстрировал работу с 10 раз   это количество трафика.
 


Kyle Cronin

+ 55 -
Масштабируемость SQLite будет сильно зависеть от используемых данных и их формата. У меня был сложный опыт работы с очень длинными таблицами (записи GPS, одна запись в секунду). Опыт показал, что SQLite будет замедляться поэтапно, частично из-за постоянной перебалансировки растущих двоичных деревьев, содержащих индексы (и с индексами с метками времени, вы просто знаете, что дерево будет сильно перебалансировано, но это жизненно важно для вашего поиск). Таким образом, в конце концов, около 1 ГБ (очень приблизительный, я знаю), запросы становятся вялыми в моем случае. Ваш пробег будет варьироваться. Следует помнить одну вещь, несмотря на все хвастовство, SQLite НЕ предназначен для хранилищ данных. Существуют различные варианты использования, не рекомендуемые для SQLite. Прекрасные люди, стоящие за SQLite, говорят сами за себя:
  Другой способ взглянуть на SQLite заключается в следующем: SQLite не предназначен для замены Oracle. Он предназначен для замены fopen ().
И это приводит к основному аргументу (не количественному, извините, но качественному), SQLite не для всех применений, тогда как MySQL может охватывать множество различных применений, даже если не в идеале. Например, вы можете иметь MySQL для хранения файлов cookie Firefox (вместо SQLite), но эта служба должна работать постоянно. С другой стороны, у вас может быть транзакционный веб-сайт, работающий на SQLite (как это делают многие люди) вместо MySQL, но ожидающий много простоев.


Теги

sqlite | scalability