Насколько масштабируемым является SQLite?
Недавно я прочитал этот вопрос о SQLite против MySQL, и в ответе указано, что SQLite плохо масштабируется, а официальный сайт вроде как подтверждает это, однако.
Насколько масштабируема SQLite и каковы ее максимальные пределы?
Ответы 10
Sqlite - это база данных рабочий стол или в процессе. SQL Server, MySQL, Oracle и их собратья - серверы.
Настольные базы данных по своей природе не являются хорошим выбором для приложения любой, которое должно поддерживать одновременный доступ для записи в хранилище данных. Это включает в себя на некотором уровне большинство когда-либо созданных веб-сайтов. Если вам даже нужно войти в систему для чего-либо, вам, вероятно, понадобится доступ на запись в БД.
Дайте ему время: у вас будет два разработчика одновременно работать с одним и тем же полем, и оно задохнется.
Что вы определяете как удушье? из вашего ответа я предполагаю, что у вас нет большого опыта работы с SQLite. SQLite заблокирует весь файл при выполнении операций, поэтому вы можете столкнуться с задержкой, но практически невозможно заставить его «задыхаться» в предложенной вами ситуации.
Эндрю, поскольку SQL Lite хорошо работает для небольших команд, не делает его масштабируемым, масштабируемым требованием является хорошее масштабирование, а это означает, что он должен хорошо работать с большими командами. Насколько мне известно, SQL Lite не масштабируется для больших групп / одновременных операций с базой данных, которые превышают довольно низкий порог.
Это должен быть принятый ответ.
@Справедливость. Этот ответ не имеет подтверждающих доказательств масштабируемости SQLite. Никто лучше не ответил.
Я думаю, вы имеете в виду "одновременный доступ / запись / доступ к хранилищу базы данных", не так ли? Также, я думаю, вы имеете в виду «файловую» базу данных, а не «настольную» базу данных, правильно? Видите ли, SQLite очень хорошо работает при чтении, хотя да, он может быть намного медленнее, чем MySQL при записи.
Это различие между серверным программным обеспечением и программным обеспечением для настольных ПК является произвольным. Единственная разница в том, принимают ли они удаленные подключения, а не какие-либо показатели производительности. Еще хуже описывать разницу как «в процессе». Например, Postgresql также является базой данных для одного процесса, как sqlite, но имеет многие функции mysql.
Sqlite масштабируется с точки зрения однопользовательского режима, у меня есть многогигабайтная база данных, которая работает очень хорошо, и у меня не было особых проблем с ней.
Но это является однопользовательский, поэтому все зависит от того, о каком масштабировании вы говорите.
В ответ на комментарии. Обратите внимание, что нет ничего, что препятствовало бы использованию базы данных Sqlite в многопользовательской среде, но каждая транзакция (фактически, каждый оператор SQL, изменяющий базу данных) блокирует файл, что предотвращает доступ других пользователей к базе данных вообще .
Так что, если вы внесли много изменений в базу данных, вы, по сути, очень быстро столкнетесь с проблемами масштабирования. С другой стороны, если у вас больше прав для чтения, чем для записи, это может быть не так уж и плохо.
Но Sqlite, конечно, будет функция в многопользовательской среде, но это не будет хорошо выполнять.
SQLite 3 поддерживает чтение, когда в него пишут другие пользователи.
Обратите внимание, что приведенные выше комментарии устарели, с новой (er) системой WAL операции записи и чтения могут выполняться одновременно, что увеличивает масштабируемость.
Можно ли создавать для экспорта записи на лету в sqlite с любых rdbms, таких как sql server, oracle и т. д.?
Вчера я выпустил небольшой сайт * для отслеживания вашего представителя, который использовал общую базу данных SQLite для всех посетителей. К сожалению, даже при небольшой нагрузке на мой хост он работал довольно медленно. Это связано с тем, что вся база данных блокировалась каждый раз, когда кто-то просматривал страницу, потому что она содержала обновления / вставки. Вскоре я переключился на MySQL, и, хотя у меня не было много времени на его тестирование, он кажется гораздо более масштабируемым, чем SQLite. Я просто помню медленную загрузку страниц и иногда получение ошибки блокировки базы данных при попытке выполнить запросы из оболочки в sqlite. Тем не менее, я отлично управляю другим сайтом из SQLite. Разница в том, что сайт статический (т.е. я единственный, кто может изменять базу данных), поэтому он отлично работает для одновременных чтений. Мораль истории: используйте SQLite только для веб-сайтов, где обновления базы данных происходят редко (реже, чем каждая загруженная страница).
редактировать: Я только что понял, что, возможно, я был несправедлив к SQLite - я не индексировал какие-либо столбцы в базе данных SQLite, когда обслуживал ее с веб-страницы. Это частично вызвало замедление, которое я испытывал. Однако наблюдение за блокировкой базы данных стоит - если у вас особенно обременительные обновления, производительность SQLite не будет соответствовать MySQL или Postgres.
другое редактирование: С тех пор, как я опубликовал это почти 3 месяца назад, у меня была возможность внимательно изучить масштабируемость SQLite, и с помощью нескольких уловок ее можно довольно масштабировать. Как я уже упоминал в своей первой редакции, индексы базы данных резко сокращают время запроса, но это скорее общее наблюдение о базах данных, чем о SQLite. Однако есть еще один прием, который можно использовать для ускорения работы SQLite: сделки. Всякий раз, когда вам нужно выполнить несколько операций записи в базу данных, поместите их в транзакцию. Вместо того, чтобы записывать (и блокировать) файл каждый раз, когда выдается запрос на запись, запись будет происходить только один раз, когда транзакция завершится.
Сайт, о котором я упоминал в первом абзаце, был снова переключен на SQLite, и он работает довольно гладко после того, как я настроил свой код в нескольких местах.
* the site is no longer available
«Классический» механизм базы данных MySQL, MyISAM, имеет те же проблемы в отношении одновременных операций чтения / записи, что и SQLite. Фактически, он блокирует каждую отдельную строку, которой он касается в операции записи, что делает невозможным масштабирование приложений с интенсивной записью. Тем не менее, он отлично справлялся со многими веб-приложениями.
Не могли бы вы тогда переписать начало своего ответа? Совершенно несправедливо судить о производительности БД без соответствующих индексов. Также транзакции сильно меняют производительность и масштабируемость SQLite.
@porneL: Верно, но SQLite без индексов был на порядок медленнее, чем MySQL без индексов, и я также добавил немного о транзакциях в свое второе редактирование. Я все еще думаю, что ответ имеет некоторый смысл - он показывает мое первоначальное наивное использование SQLite и то, насколько плохой была его производительность. Я ожидаю, что новички в этой платформе столкнутся с аналогичными проблемами, и я надеюсь, что они смогут идентифицировать себя с первым абзацем, затем прочитать следующие правки и понять, что есть способы ускорить SQLite для достижения приемлемой производительности.
Нет упоминания о разделении информации о производительности чтения и записи? SQLite превосходит MySQL по скорости чтения, не так ли? Я имею в виду, особенно если вы используете индекс? И он работает еще быстрее, если вы смонтируете файл базы данных на томе со свойством noatime или если вы запустите команду «chattr -R + A {database dir}» в каталоге базы данных.
Еще один важный момент, который следует отметить, - это нынешняя тенденция виртуального хостинга. У многих серверов общего хостинга, с которыми я работал, были клиенты, которые действительно забивают серверы MySQL, что делает MySQL не лучшим выбором, если у вас нет тяжелых операций записи. С другой стороны, для операций чтения или записи небольшого и среднего размера производительность SQLite может превосходить MySQL (особенно если индексы используются правильно и свойство noatime отключено в каталоге базы данных), но только для этих конкретных типов перегруженных планов общего хостинга.
Не могли бы вы поделиться с нами примерно, сколько посещений в секунду получает ваш сайт?
@NoobOverflow Я отключил сайт некоторое время назад, поэтому не совсем помню. Это было немного - порядка сотен пользователей в день на пике, но не более того. Однако, если вы хотите выполнять в основном чтение, а не запись, SQLite может масштабироваться намного больше.
Это примерно первая проблема, с которой сталкивается каждый, кто работает с SQLite: sqlite.org/faq.html#q19. Это также проблема с заданием подобных вопросов: только эксперты могут дать честный ответ.
У меня также были проблемы с параллелизмом с обновлениями на веб-сайте, пока я не начал упаковывать пакетные обновления / вставки в транзакции. (даже если их всего пара) Очевидно, это приводит к гораздо более высокой производительности блокировки.
В более новых версиях SQLite также есть функция упреждающей записи (WAL), которая может избавить от некоторых проблем, связанных с циклами чтения / записи. Вещи меняются.
@KyleCronin Как вы обновляете схему базы данных и справочные данные при развертывании новой версии вашего сайта?
@KonstantinTarkus Когда дело доходит до развертывания обновлений схемы, SQLite на самом деле не отличается от других баз данных (например, MySQL и Postgres), и методы, используемые для их обновления, скорее всего, будут работать и для SQLite.
@KonstantinTarkus Например, по возможности я стараюсь убедиться, что мои обновления схемы обратно совместимы с производственным кодом. Затем я обновляю схему в производственной среде, а затем отправляю изменения кода, которые зависят от новой схемы.
Не по теме: я действительно хотел проголосовать за этот ответ, но текущее количество 420 делает его идеальным ответом, не нуждающимся в дополнительной проверке. ;)
Современный SQLite достаточно масштабируемый. Если вы используете транзакции, вы можете вносить до 10 000 изменений в секунду. Параллелизм - единственная проблема SQLite. Однако это можно преодолеть, написав собственный сервер TCP / IP с серверной частью SQLite (то есть настраиваемым API). Ваше приложение подключается к этому серверу TCP / IP и отправляет JSON, завершенный новой строкой. Серверный процесс извлекает JSON, разговаривает с БД и возвращает ответ в виде JSON, завершенного новой строкой, периодически сбрасывая транзакции (например, каждые 3 секунды). Такой сервер наивный легко обрабатывает ~ 4000 запросов / сек на одном хосте.
Прежде чем кто-то укажет на то, что я описываю, выглядит как mini-MySQL или Postgres, это определенно так ... до определенной степени. Однако сервер TCP / IP обычай позволяет кэшировать информацию из базы данных в оперативной памяти, к которой будет осуществляться регулярный доступ. Ключ в том, что все изменения БД проходят через настраиваемый сервер. Пользовательский сервер с поддержкой SQLite, который представляет собой специализированный API, может легко превзойти по производительности эквивалентное приложение с поддержкой MySQL / Postgres, сохраняя при этом все преимущества серверной части базы данных. В отличие от формальных приложений БД, SQLite является переносимым, и теперь вы знаете, как сделать его масштабируемым.
Подумайте об этом так. SQL Lite будет заблокирован каждый раз, когда кто-то его использует (SQLite не блокируется при чтении). Таким образом, если вы обслуживаете веб-страницу или приложение, которое имеет несколько одновременных пользователей, только один может использовать ваше приложение одновременно с SQLLite. Так что тут есть проблема с масштабированием. Если это приложение для одного человека, например, Музыкальная библиотека, в которой вы храните сотни названий, рейтингов, информации, использования, воспроизведения, времени воспроизведения, тогда SQL Lite будет прекрасно масштабироваться, удерживая тысячи, если не миллионы записей (требуется жесткий диск)
MySQL, с другой стороны, хорошо работает для серверных приложений, где люди будут использовать его одновременно. Он не блокируется и довольно большой по размеру. Таким образом, для вашей музыкальной библиотеки MySql будет лишним, так как его увидит только один человек, ЕСЛИ это не общая музыкальная библиотека, в которую тысячи добавляют или обновляют ее. Тогда можно будет использовать MYSQL.
Так что теоретически MySQL масштабируется лучше, чем Sqllite, потому что он может обрабатывать несколько пользователей, но это излишек для одного пользовательского приложения.
s / использует его / пишет в него. sqlite не блокирует чтение.
что ж, ваш ответ может быть легко неверно истолкован. SQLite блокирует только запросы на запись. Мы используем SQLite для более чем 50 ГБ медицинских данных в реляционной форме и обслуживаем сотни одновременных веб-клиентов для просмотра и запросов. Его производительность чтения никогда не хуже, чем у недавнего MySQL.
MyISAM MySQL не намного лучше для одновременного доступа, чем SQLite. MySQL часто использует блокировки на уровне таблицы и не выполняет одновременную запись, за исключением нескольких случаев, когда расположение MyISAM является оптимальным. Если вы не выберете InnoDB (у которого есть свои проблемы, такие как никогда не сжимающийся файл данных), вам может быть не намного лучше с MySQL.
Возможно, стоит проверить НАСТОЯЩИЙ SQL Server, сервер базы данных, построенный на SQLite.
Я не думаю, что какой-либо сайт гарантирует потратить 299 долларов на «НАСТОЯЩИЙ SQL Server», когда большинство сайтов не получают достаточно трафика, чтобы даже начать достигать пределов SQLLite.
Веб-сайт SQLite (та часть, на которую вы ссылались) указывает, что его можно использовать в различных многопользовательских ситуациях.
Я бы сказал, что с ним можно справиться совсем немного. По моему опыту, это всегда было очень быстро. Конечно, вам нужно проиндексировать свои таблицы, и при кодировании с учетом этого вы должны убедиться, что используете параметризованные запросы и тому подобное. Практически то же самое, что и с любой базой данных для повышения производительности.
и использовать транзакции. Это очень важно для SQLite.
Вы читали эту документацию по SQLite - http://www.sqlite.org/whentouse.html?
SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.
Я ОЧЕНЬ согласен с этим. 99% веб-сайтов должны нормально обрабатываться с помощью SQLite, если вы этого хотите. Но, с другой стороны, 99% веб-трафика направляется на 1% крупнейших веб-сайтов.
Показатель «100 тысяч обращений в день» - полная чушь. «Хит» обычно определяется как HTTP GET, и веб-сайт с кучей нарезанных изображений может получить 40+ «хитов» за просмотр страницы - ни одно из них не касается БД. Даже если документы совершают ошибку при нажатии == pageview, это все равно вводит в заблуждение. SQLite блокирует всю БД при записи. Хотя он может доблестно обслуживать 100 тысяч просмотров страниц людьми, просто просматривающими записи, он развалится в приложениях, требующих большого количества записей (электронная коммерция, доска сообщений и т. д.).
Я думаю, что веб-сервер (в цифрах 1), обслуживающий множество клиентов, появляется на бэкэнде с одним подключением к базе данных, не так ли?
Таким образом, в базе данных нет одновременного доступа, поэтому мы можем сказать, что база данных работает в «однопользовательском режиме». В таких обстоятельствах нет смысла обсуждать многопользовательский доступ, поэтому SQLite работает так же хорошо, как и любая другая серверная база данных.
Спасибо, GateKiller, но укажите «веб-сайт с небольшим объемом».
Масштабируемость SQLite будет сильно зависеть от используемых данных и их формата. У меня был тяжелый опыт работы с очень длинными таблицами (записи GPS, одна запись в секунду). Опыт показал, что SQLite будет замедляться поэтапно, отчасти из-за постоянной перебалансировки растущих двоичных деревьев, содержащих индексы (а с индексами с отметкой времени вы просто знать, это дерево будет сильно перебалансировано, но это жизненно важно для вашего поиски). Таким образом, в конечном итоге при объеме около 1 ГБ (я знаю, это очень приблизительный показатель) в моем случае запросы становятся вялыми. Ваш пробег будет отличаться.
Следует помнить, что, несмотря на все хвастовство, SQLite НЕ предназначен для хранения данных. Существуют различные варианты использования не рекомендуется для SQLite. Прекрасные люди, стоящие за SQLite, говорят это сами:
Another way to look at SQLite is this: SQLite is not designed to replace Oracle. It is designed to replace fopen().
И это приводит к главному аргументу (не количественному, извините, но качественному), SQLite не для всех применений, тогда как MySQL может охватывать множество разнообразных применений, даже если не в идеале. Например, у вас может быть MySQL для хранения файлов cookie Firefox (вместо SQLite), но вам потребуется, чтобы эта служба работала постоянно. С другой стороны, у вас может быть транзакционный веб-сайт, работающий на SQLite (как многие люди) вместо MySQL, но вы ожидаете большого времени простоя.
Вы можете обойти проблему наличия очень больших индексированных таблиц, сегментируя ваши данные, например один стол в день / неделю. SQLite даже позволяет вам разбивать таблицы на отдельные файлы базы данных, а затем использовать ATTACH DATABASE для создания подключения к виртуальной базе данных со всеми таблицами (однако жестко ограничивается 62 базами данных).
SQLite управляет веб-сайтом sqlite.org и другими сайтами с большим объемом трафика. Они предполагают, что если у вас есть менее 100 тыс. попаданий в день, SQLite должен работать нормально. И это было написано до того, как появилась функция «Ведение журнала с опережением записи».
Если вы хотите ускорить работу с SQLite, сделайте следующее:
- перейти на SQLite 3.7.x
- Включить ведение журнала с упреждающей записью
- Выполните следующую директиву: «PRAGMA cache_size = Number-of-pages;» Размер по умолчанию (количество страниц) составляет 2000 страниц, но если вы увеличите это число, вы увеличите объем данных, которые работают прямо из памяти.
Вы можете посмотреть мое видео на YouTube под названием «Повышение производительности SQLite с помощью ведения журнала с опережением записи», которое показывает, как использовать ведение журнала с упреждающей записью и демонстрирует 5-кратное улучшение скорости записи.
Я бы не согласился с утверждением: «Это касается практически всех когда-либо созданных веб-сайтов». комментарий. Если сайт загружен, вы правы. Например, Trac по умолчанию использует SQLite и отлично работает для небольших команд.