Почему и как базы данных используют один файл для хранения всех данных?

Ответ 1

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

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

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

Эта блокировка может быть реализована с использованием семафоров или других механизмов синхронизации в зависимости от компромиссов производительности.

Ответ 2

Вправо, данный файл может иметь только один процесс с открытым файловым дескриптором, иначе разные процессы могут перезаписать работу друг друга. Как правило, все операции ввода-вывода в базе данных должны выполняться процессом РСУБД. Затем все приложения отправляют свои запросы через некоторую межпроцессную связь (включая сеть) и получают результаты. Таким образом, физический ввод-вывод файла базы данных является централизованным.

Кроме того, на практике для реализаций RDBMS имеется поток диспетчера блокировок для управления доступом к подразделам файла, таблице, странице или строке, в зависимости от реализации РСУБД. Это создает "узкое место", потому что в то время как RDBMS может иметь много потоков, выполняющих запросы и выполняющих сетевую связь, но одновременный доступ к определенному разделу базы данных по-прежнему должен стоять в очереди, чтобы получить блокировки. Было бы очень сложно сделать управление блокировкой полностью параллельным.

Что касается отдельного файла или нескольких файлов, то плюсы и минусы также зависят от реализации РСУБД. Одним из примеров является MySQL InnoDB, который по умолчанию использует однофайловый подход. Но он не знает, как сжать файл, если вы удалите кучу данных; он просто отмечает некоторое пространство в файле как "свободное", которое будет использоваться последующими вставками. Даже если вы удалите всю таблицу, файл никогда не сжимается. Но если вы выбрали опцию "файл за стол" при настройке табличного пространства InnoDB и вы удаляете таблицу, InnoDB может удалить файл для этой таблицы и, следовательно, освободить место на диске.

Ответ 3

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

Почему поставщик СУБД откажется от собственного управления вводом-выводом и т.д.

Control

Когда большинство систем СУБД выросли (Oracle, DB2, Sybase ASE {SQL Server является кузеном для Sybase ASE}), файловые системы операционных систем были не такими продвинутыми, как сегодня, но быстро развивались (Oracle была написана в 1979 году!!, Sybase в 1987 году). Предполагая, что ОС может делать всевозможные причудливые вещи, которые были быстрыми и безопасными, не всегда давались. Поставщики СУБД написали свои собственные библиотеки ввода-вывода, чтобы уменьшить вероятность того, что они не будут затронуты причудами операционной системы или устареют по мере развития технологии.

Это гораздо менее распространено сейчас (MySQL, PostgreSQL, SQLite и т.д. этого не делают) - даже SQL Server превратил большую часть управления обратно в Windows, потому что команда Windows тесно работала с командой SQL Server для оптимизации рабочей нагрузки СУБД.

Безопасность

Сохранение жесткого контроля всего файла данных позволяет СУБД обеспечить, чтобы записи выполнялись, когда они этого захотели, а не когда ОС чувствует себя так. Сохранение своих собственных кэшей данных гарантирует, что ОС не будет думать, что на некоторых страницах с низкоуровневыми журнальными работами выходят важные данные базы данных.

Согласованность

Oracle, Sybase ASE и т.д. - очень дорогостоящие системы, которые очень сложны. Если вы потратили $10 млн на установку СУБД, и она медленно (или, что еще хуже, искала данные!) Из-за какой-то сумасшедшей ошибки в вашей конкретной ревизии ядра вашей ОС, с кем бы вы обвинили? Поставщик СУБД. Роллинг вашего ввода-вывода, управления блокировкой, управления concurrency, потоковой передачи и т.д., Безусловно, является сложным способом сделать это, но когда вам абсолютно необходимо повторяемое, последовательное поведение из вашей СУБД в широком диапазоне операционных систем, вывести ОС из уравнения как можно больше.

Опять же, поскольку ОС созрели и выросли, многие из более новых систем пытались максимально использовать возможности уровня ОС, но даже у MySQL есть несколько пулов буферов, которые вы можете настроить в my.cnf

Ответ 4

Соответствующая записка. Я считаю, что это рекомендация MSFT создать файловую группу для системных таблиц и одну для других объектов. Другой может быть создан для хранения индексов. Мы этого не делаем, поскольку ни одно из наших приложений не требует такой высокой производительности. Это также увеличит сложность обслуживания.