Конкурентность

Обработка конкурентности

DuckDB имеет две настраиваемые опции для конкурентности:

Один процесс может как читать, так и записывать в базу данных.
Несколько процессов могут читать из базы данных, но ни один процесс не может писать (access_mode = 'READ_ONLY').

При использовании опции 1, DuckDB поддерживает несколько потоков записи, используя комбинацию MVCC (Управление конкурентностью с множественными версиями) и оптимистического управления конкурентностью (см. Конкурентность в пределах одного процесса), но всё внутри этого одного процесса записи. Причина этой модели конкурентности заключается в возможности кеширования данных в оперативной памяти для ускорения аналитических запросов, вместо постоянного обращения к диску при каждом запросе. Она также позволяет кешировать указатели функций, каталог базы данных и другие элементы, чтобы последующие запросы к одному соединению были быстрее.

DuckDB оптимизирован для операций с большими объемами данных, поэтому выполнение многих мелких транзакций не является основной целью проектирования.

Конкурентность в пределах одного процесса

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

Запись в DuckDB из нескольких процессов

Автоматическая поддержка записи в DuckDB из нескольких процессов не предусмотрена и не является основной целью проектирования (см. Обработка конкурентности).

Если нескольким процессам необходимо писать в один и тот же файл, возможны несколько шаблонов проектирования, но их необходимо реализовать в прикладной логике. Например, каждый процесс может получить блокировку взаимного исключения для межпроцессного доступа, затем открыть базу данных в режиме чтения/записи и закрыть её по завершении запроса. Вместо использования блокировки взаимного исключения, каждый процесс может повторно пытаться подключиться, если другой процесс уже подключен к базе данных (не забывая закрыть соединение по завершении запроса). Другой вариант — выполнение многопроцессных транзакций в базе данных MySQL, PostgreSQL или SQLite и использование расширений DuckDB для MySQL, PostgreSQL или SQLite для периодического выполнения аналитических запросов к этим данным.

Дополнительные варианты включают запись данных в файлы Parquet и использование возможностей DuckDB по чтению нескольких файлов Parquet, аналогичный подход к файлам CSV или создание веб-сервера для обработки запросов и управления чтением и записью в DuckDB.

Оптимистическое управление конкурентностью

DuckDB использует оптимистическое управление конкурентностью, подход, который, как правило, считается наиболее подходящим для аналитических систем баз данных с интенсивным чтением, так как он ускоряет обработку запросов на чтение. В результате любые транзакции, изменяющие одни и те же строки одновременно, приведут к ошибке конфликта транзакций:

Transaction conflict: cannot update a table that has been altered!

Подсказка. Обходным решением при возникновении конфликта транзакций часто является повторное выполнение транзакции.