SQlite / Firebird: Кто-нибудь из них поддерживает множественный одновременный доступ для записи?

Question

Вопрос. В настоящее время я храню данные приложения ASP.net в файлах XML.

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

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

Однако я не уверен, что SQlite или Firebird могут обрабатывать несколько одновременных прав записи.
И я, конечно, не хочу снова ту же проблему.
Кто-нибудь знает?
SQlite, конечно, лучше известен, но какой из них лучше - SQlite или Firebird? Я склонен говорить «Жар-птица», но на самом деле не знаю.

Никаких рекомендаций по MS-Access или MS-SQL-express, пожалуйста, я здравомыслящий человек.

Answer 1

SQLITE может быть настроен для изящной обработки одновременных записей в большинстве ситуаций. Что происходит, когда один поток или процесс начинает запись в БД, файл блокируется. Когда вторая попытка записи выполняется и обнаруживает блокировку, она на короткое время откатывается, прежде чем предпринимать новую попытку записи, пока она не завершится успешно или не истечет время ожидания. Время ожидания настраивается, но в остальном все это происходит без необходимости делать что-либо особенное в коде приложения, кроме включения опции, например:

// set SQLite to wait and retry for up to 100ms if database locked
sqlite3_busy_timeout( db, 100 );

Все это работает очень хорошо и без каких-либо трудностей, за исключением двух обстоятельств:

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

2. Если база данных совместно используется разными процессами, работающими на разных машинах, совместно использующих подключенный к сети диск. Многие операционные системы имеют ошибки в сетевых дисках, которые делают блокировку файлов ненадежной. На это нет ответа. Если вам нужно совместно использовать базу данных на диске, смонтированном в сети, вам нужен другой механизм базы данных, такой как MySQL.

У меня нет опыта работы с Firebird. В таких ситуациях я использовал SQLITE для многих приложений в течение нескольких лет.

Answer 2

Я выберу Firebird по многим причинам и для этого тоже

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

Может быть, вы также можете проверить это

Answer 3

Рассматривали ли вы Berkeley DB с поддержкой SQLite API для SQL?

Answer 4

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

Транзакционный sqlite? в C #

Answer 5

Я бы добавил # 3 к списку из ravenspoint выше: если у вас есть большой колл-центр или центр обработки заказов, скажем, где десятки людей могут одновременно нажимать кнопку СОХРАНИТЬ, даже если каждый из них Обновляя или вставляя только одну запись, вы можете столкнуться с проблемами, используя подход «занятое время ожидания».

Для сценария № 3 идеальный механизм SQL, который может сериализоваться, идеален; менее идеальным, но обслуживаемым является dbms, который может блокировать записи в байтовом диапазоне общего файла. Но имейте в виду, что даже блокировка записи в байтовом диапазоне будет недостаточной для большого числа одновременных записей, когда новые записи добавляются в конец файла, как камбуз на конце грузового поезда, так что несколько процессов пытаются в то же время, чтобы установить блокировку на тот же диапазон байтов. С другой стороны, схема блокировки записи в диапазоне байтов в сочетании с подходом разреженного файла хешированного ключа (например, старая база данных Revelation / OpenInsight для локальных сетей) будет намного лучше ISAM для этого сценария. *