SQLite и concurrency

Ответ 1

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

Я бы порекомендовал какое-то другое решение, например MySQL или PostgreSQL, оба могут быть написаны достаточно хорошо. Итак, если бы я был вами, я бы включил свои настройки в сценарии установки.

Чтобы избежать пламенной войны между сторонниками SQLite и ненавистниками, позвольте мне обратить внимание на часто упоминаемый документ SQLite When-To-Use (я считаю, что это считается достоверным источником). Здесь они указывают следующее:

Ситуации, в которых может быть лучше работает РСУБД/сервер

Высокий Concurrency

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

Я думаю, что в упомянутом вопросе задействованы многие записи, и если OP пойдет на SQLite, это приведет к немасштабируемому решению.

Ответ 2

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

sqlite3 полностью совместим с ACID, что означает, что он обеспечивает атомные коммиты, что не является ни MySQL (как бы это ни было возможно), ни Oracle не может похвастаться. Подробнее здесь

Кроме того, sqlite3 имеет обманчиво простой механизм для обеспечения максимального concurrency (который также является потокобезопасным), как описано в их Блокировании файлов и concurrency.

Своей собственной оценкой (sqlite3 developers), sqlite3 способен до 50 000 INSERT в секунду - теоретический максимум, который ограничен скоростью вращения диска. ACID-совместимость требует, чтобы sqlite3 подтвердил, что фиксация базы данных записана на диск, поэтому транзакция INSERT, UPDATE или DELETE требует двух полных оборотов диска, тем самым эффективно уменьшая количество транзакций до 60/с на дисководе 7200 об/мин. Это описано в часто задаваемых вопросах sqlite, связанных с другим ответом, и факт дает некоторое представление о пропускной способности данных двигателя в производстве. Но как насчет одновременного чтения и записи?

Зафиксированный файл и concurrency документ, связанный ранее, объясняют, как sqlite3 избегает "startvation writer" - условие, при котором доступ к базе данных с большой доступностью предотвращает процесс/поток, пытающийся записать в базу данных, после получения блокировки. Эскалация состояния блокировки от SHARED до PENDING до EXCLUSIVE происходит, когда sqlite3 встречает инструкцию INSERT (или UPDATE или DELETE), а затем снова COMMIT, что означает, что полная блокировка базы данных задерживается до последнего момента до фактической записи. Результатом умного механизма sqlite для обработки блокировки файлов является то, что если писатель присоединяется к очереди (блокировка блокировки), существующие чтения (блокировки SHARED) будут завершены, предоставит блокировку EXCLUSIVE для процесса записи, а затем возобновит чтение. Это занимает всего несколько миллисекунд, а это означает, что эффективная пропускная способность транзакций вряд ли изменится с приведенной выше скорости 60/s.

Я считаю, что по умолчанию sqlite3 WAIT на блокировке EXCLUSIVE составляет 3 секунды, поэтому учитывая тот факт, что 60 транзакций в секунду являются разумным ожиданием и что вы пытаетесь писать в базу данных в среднем каждые 10 секунд - я бы сказал sqlite3 хорошо подходит для этой задачи и потребует только кластеризации, только если ваш трафик увеличится в 500 раз.

Неплохо и идеально подходит для вашего требования.

Ответ 3

Вот что говорит SQLite о подходящем использовании SQLite: http://www.sqlite.org/whentouse.html В частности, эта страница говорит, что SQLite хорош для низкого уровня сайты среднего трафика, именно то, что вы созерцаете.

Кажется, что SQLite будет работать для вас, если вы не ожидаете существенного роста. В зависимости от того, что вы делаете в каждом запросе, я ожидал бы, что частота запросов 0,17 запросов в секунду будет хорошо соответствовать возможностям SQLite.

Для хорошего пользовательского опыта вы должны спроектировать свой сайт, чтобы запросы, необходимые для обслуживания одного запроса, составляли ~ 200 миллисекунд. Чтобы достичь этого, наборы результатов, вероятно, не должны касаться более нескольких рядов баллов; и должны полагаться на индексы, а не на полное сканирование таблицы. Если вы нажмете на это, у вас будет достаточно запаса для подачи 5 запросов в секунду (на пике). Это 30-кратное требование, которое вы заявляете в своем вопросе.

Ответ 4

В SQLite FAQ описывается эта тема: http://www.sqlite.org/faq.html (см. "5) Можно ли использовать несколько приложений или несколько экземпляров одного и того же приложения один файл базы данных одновременно?" )

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

Ответ 5

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

Комментарии, касающиеся Apache concurrency, верны: один сервер Apache может обслуживать несколько запросов, число зависит от количества процессов. Большинство серверов, на которых я запускаю, настроен на 3-5 процессов, а на больших установках - до 20. Дело здесь в том, что SQLite может больше обрабатывать веб-сайт малого и среднего трафика, так как он может делать тысячи вставок второй.

Я планирую использовать SQLite для моего текущего проекта, но для того, чтобы быть в безопасности, я полностью намерен использовать BEGIN TRANSACTION и COMMIT для любой записи или concurrency -чувствительных частей.

Внизу, как обычно, прочитайте руководство.

Ответ 6

Дополнительно к обсуждению выше о sqlite3, Добавлена ​​еще одна потрясающая функция в sqlite v 3.7.0 (режим WAL) Режим записи в режиме заголовка , в котором вы можете читать из нескольких процессов и можете писать с помощью один процесс в то же время.

посмотреть; http://www.sqlite.org/wal.html