Если в Linux операции с файлами в пределах потока блокирующие, то как тогда работают БД?

Question

[tamtakoe]

Создают пул потоков в которых читают/пишут файл базы и забивают ими память? Или есть версии Linux с неблокирующим вводом-выводом или у БД своя файловая система?

Comments

[pfg21]

Через mmap отобразить файл в память и писать одновременно в разные участки.
Это будет конечно не прямая мультипоточная запись в файл.

Answer 1

[mayton2019]

как тогда работают БД?

Пускай Ораклисты меня поправят но по моему DBMS Oracle не использует потоки. По крайней мере
на уровне терминологии и документации все составные части Oracle - это процессы PMON, SMON, DBW...
И пользовательские сессии тоже представлены процессами. По крайней мере отстрел пользовательских
сессий через orakill / kill тоже привязан архитектуре процессов.

или у БД своя файловая система?

Да Oracle может использовать ФС ext3/4 например или работать поверх технологии ASM (это 2-в-1 и менеджер
томов и кластерная ФС) но мне кажется что к сути вопроса это не относится.

По старой памяти у меня в голове крутится параметр FILESYSTEMIO_OPTIONS, он отвечает за тип I/O
операций которые DBMS будет использовать. Там кажется ASYNC, DIRECT и их комбинации. Вобщем
почитай тоже по этому вопросу.

Answer 2

[res2001]

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

Думаю ваш вопрос не связан с п.1, т.к. это больше про параллельное программирование, а не про файлы и БД.
Файловые операции легко могут не блокировать поток - асинхронный ввод/вывод.
Файл можно открыть с монопольным доступом и с общим доступом. В общем доступе этот же файл может открыть и другое приложение одновременно с вашим.
При общем доступе вы можете блокировать какую-то область файла и работать с этой областью "монопольно".
БД открывают свои файлы в монопольном режиме.
В разных потоках одного приложения вы можете открыть файл один раз и работать с одним и тем же дескриптором файлов из разных потоков. Но это может создать кучу проблем с целостностью структуры файла, если много потоков будут не согласованно писать в файл.
Файловые операции ОЧЕНЬ медленные. Поэтому все нормальные базы данных работают через свой собственный кэш. Поэтому там, обычно нет кучи потоков, которые лопатят файл БД. Движок SQL берет данные из кэша, есть некий "менеджер кэша" - отдельный поток, которому движок дает запрос на данные, если данных в кэше прямо сейчас нет, то менеджер кэша читает данные из файла в кэш и отдает эти данные запрашиваемому потоку. Чтение файла наверняка то же идет не на прямую, а запросы на чтение ставятся в очередь и возможно какой-то другой поток (или тот же менджер кэша) по очереди читает необходимые данные. Аналогично и с записью - через кэш и последующую очередь на запись.
Если запустить MS Sql Server с настройками по умолчанию с достаточно большой по объему базой он довольно быстро отожрет в компе вообще всю свободную память (конечно, если БД меньше, чем объем ОЗУ, то всю память не отожрет). Не то что бы ему очень нужно прямо сейчас вот столько памяти (он может в это время вообще простаивать), просто он начитал данные в кэш.
Как-то так я это вижу.