SQlite/Firebird: Кто-нибудь из них поддерживает множественный одновременный доступ для записи?
Вопрос: В настоящее время я храню данные приложения ASP.net в файлах XML.
Теперь проблема в том, что у меня есть асинхронные операции, что означает, что я столкнулся с проблемой одновременного доступа к записи в файл XML...
Теперь я рассматриваю возможность перехода к встроенной базе данных, чтобы решить эту проблему. В настоящее время я рассматриваю SQlite и встраиваемый Firebird.
Однако я не уверен, что SQlite или Firebird могут обрабатывать несколько одновременных прав записи.
И я, конечно, не хочу снова ту же проблему.
Кто-нибудь знает?
SQlite, конечно, лучше известен, но какой из них лучше - SQlite или Firebird? Я имею тенденцию говорить Firebird, но я действительно не знаю.
Никаких рекомендаций MS-Access или MS-SQL-express, пожалуйста, я нормальный человек.
5 ответов
Я выберу Firebird по многим причинам и для этого тоже
SQLite не поддерживает параллельные транзакции, поэтому если вашему встроенному приложению требуется два или более соединений, они должны быть сериализованы. Встроенную базу данных Firebird легко обновить до полностью разделяемой базы данных - просто измените общую библиотеку.
Может быть, вы также можете проверить это
SQLITE можно настроить для изящной обработки одновременных записей в большинстве ситуаций. Что происходит, когда один поток или процесс начинает запись в БД, файл блокируется. Когда вторая попытка записи выполняется и обнаруживается блокировка, она на короткое время откатывается, прежде чем предпринимать новую попытку записи, пока она не завершится успешно или не истечет время ожидания. Время ожидания настраивается, но в остальном все это происходит без необходимости делать что-либо особенное в коде приложения, кроме включения опции, например:
// set SQLite to wait and retry for up to 100ms if database locked
sqlite3_busy_timeout( db, 100 );
Все это работает очень хорошо и без каких-либо трудностей, за исключением двух обстоятельств:
Если приложение выполняет много операций записи, скажем, тысячи вставок, все за одну транзакцию, то база данных будет заблокирована на значительный период времени и может вызвать проблемы для любого другого приложения, пытающегося выполнить запись. Решение состоит в том, чтобы разбить такие большие записи на отдельные транзакции, чтобы другие приложения могли получить доступ к базе данных.
Если база данных совместно используется разными процессами, работающими на разных машинах, используется общий сетевой диск. Многие операционные системы имеют ошибки в сетевых дисках, которые делают блокировку файлов ненадежной. На это нет ответа. Если вам нужно совместно использовать базу данных на диске, смонтированном в сети, вам нужен другой механизм базы данных, например MySQL.
У меня нет опыта работы с Firebird. Я использовал SQLITE в подобных ситуациях для многих приложений в течение нескольких лет.
Похоже, что SQLite подойдет. Мы используем SQLite во многих производственных приложениях, он поддерживает, на самом деле, он предпочитает транзакции, которые имеют большое значение для обработки параллелизма.
Я бы добавил № 3 в список с ravenspoint выше: если у вас есть большой колл-центр или центр обработки заказов, скажем, где десятки людей могут одновременно нажимать кнопку СОХРАНИТЬ, даже если каждый обновляет или вставляет только одна запись, вы можете столкнуться с проблемами, используя подход занятого тайм-аута.
Для сценария № 3 идеальным является механизм SQL, который может сериализоваться; менее идеальным, но обслуживаемым является dbms, который может блокировать записи в байтовом диапазоне общего файла. Но имейте в виду, что даже блокировка записи в байтовом диапазоне будет недостаточной для большого числа одновременных записей, когда новые записи добавляются в конец файла, как камбуз на конце грузового поезда, так что несколько процессов пытаются одновременно установить блокировку на тот же диапазон байтов. С другой стороны, схема блокировки записи в байтовом диапазоне в сочетании с подходом разреженного файла хешированного ключа (например, старая база данных Revelation/OpenInsight для локальных сетей) будет намного превосходить ISAM для этого сценария.