Почему Windows / Linux не используют реляционные базы данных (RDBMS)?

Почему Windows / Linux не использует реляционные базы данных ( RDBMS )?

Я знаю, что они используют файловые системы для хранения всех данных, но не думаете ли вы, что более эффективно использовать базы данных, которые мы используем в веб-сайтах / веб-приложениях?

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

Это не дубликат. Когда следует использовать базу данных предпочтительнее, чем анализировать данные из текстового файла? Я говорю только о контексте операционной системы, и этот вопрос обобщен.

Сегодня большинство систем управления базами данных (например, PostGreSQL , MongoDB и т. Д.) Внутренне хранят свои данные в файлах ОС (в прошлом некоторые СУБД использовали непосредственные разделы сырых дисков).

^{На недавних компьютерах, все еще использующих вращающиеся жесткие диски , диск настолько медленный - относительно ЦП или ОЗУ - что добавление нескольких слоев программного обеспечения не имеет значения. Технология SSD может немного изменить это, и некоторые файловые системы оптимизированы для SSD.}

Файлы присутствуют в большинстве операционных систем в целом по историческим и социальным причинам (в частности, компиляторы C и большинство инструментов - редакторы, компоновщики - хотят файлы, поэтому возникает проблема с курицей и яйцами), а также потому, что существует множество очень хороших файлов. системные реализации.

Кстати, некоторые важные системные средства могут использовать базы данных. Например, в Linux PAM можно настроить на использование информации в базах данных (но на практике это редко делается). Кроме того, некоторые почтовые серверы могут хранить некоторые или большую часть своих данных в базах данных (например, Exim ).

Файлы представляют собой несколько более низкие абстракции, чем базы данных, поэтому их проще реализовать (как файловые системы и уровень VFS в ядре Linux) и быстрее использовать. В частности, операции с файлами гораздо более ограничены, чем с базами данных. Фактически, вы могли видеть файлы или файловые системы как некоторые очень ограниченные базы данных!

Вы можете разработать операционную систему без каких - либо файлов , но с каким - либо другим ортогональной инерционностью механизмом (например , имеющей каждый процесс быть стойким, то вы все равно много явно о хранении, так как операционная система управляют постоянными ресурсами). Это было сделано в нескольких академических операционных системах ⁽¹⁾ (а также на машинах Smalltalk и Lisp 1980-х годов, как-то в IBM System i , также называемой AS / 400 , и в некоторых игрушечных проектах, связанных с osdev), но когда вы разрабатываете свою ОС таким способом, вы не можете использовать многие существующие инструменты (например, вам также нужно создать компилятор и пользовательский интерфейс с нуля, а это много работы).

Обратите внимание, что операционным системам микроядра могут не понадобиться файлы, предоставляемые уровнями ядра, поскольку файловые системы являются просто серверами приложений (например, трансляторы Hurd, работающие в пользовательской среде). Посмотрите также на подход unikernel в современном MirageOS

Linux (и, вероятно, Windows, которая получила большую часть своего вдохновения от VMS и Unix ) нужны файлы для работы. По крайней мере, инициализация программа (первая программа запускается ядро) должна быть исполняемой хранится в файл (часто /sbin/init, но это может быть Systemd в эти дни), и (почти) все остальные программы запускаются с execve (2 ) поэтому syscall должен храниться в файле. Однако FUSE позволяет вам придавать файловую семантику не-файловым вещам.

Также обратите внимание, что в Linux (и, возможно, даже в Windows, которую я не знаю и никогда не использовал) sqlite - это библиотека, управляющая некоторой базой данных SQL в файлах и предоставляющая API для этого. Широко известно, что Android (вариант Linux) использует много файлов sqlite (но у него все еще есть POSIX-подобная файловая система).

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

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

Примечание 1: постоянные академические ОС включают Lisaac & Grasshopper , но эти академические проекты, похоже, неактивны. Посмотрите также на http://tunes.org/ ; он неактивен, но получил много дискуссий по таким темам.

Примечание 2: понятие файла с течением времени сильно изменилось (посмотрите на этот ответ о моем первом опыте программирования): первая MSDOS на компьютерах IBM 1980-х годов (без каталогов!), VMS - на Vaxen 1978 года - (имел обе записи с фиксированной записью) файлы и последовательные файлы, с примитивной системой управления версиями), мейнфреймы 1970-х годов ( IBM / 370 с OS / VS2 MVS ) имели совершенно другое представление о файлах и файловых системах (в частности, потому что в то время отношение времени доступа к жесткому диску к время доступа к основной памяти составляло несколько тысяч, поэтому в то время диск работал относительно быстрее, чем сегодня, даже если современные диски абсолютнобыстрее, чем в прошлом веке, сегодня соотношение скорости процессора и диска составляет около миллиона; но теперь у нас есть твердотельные накопители). Кроме того, файлы менее полезны (или даже бесполезны), когда память постоянна (как на магнитном барабане CAB500 , 1960-е годы или будущие компьютеры, использующие MRAM ).

Хотя это основано на мнении, я думаю, что это просто еще один исторический артефакт. Ранние ОС использовали простую конструкцию файловой системы для производительности, которая была достаточно сильно привязана к характеристикам оборудования, доступного в то время, и с тех пор так было. Трудно изменить старые API чтения / записи файлов на более транзакционные API запросов / вставок после их создания.

Все текущие файловые системы требуют обратной совместимости с этими старыми API.

Microsoft действительно задумалась о замене файловой системы базирующейся на RDBMS системе в разработке Longhorn . Для них это было слишком большим изменением, но вы видите, что их усилия продолжаются в форме поиска Windows (где СУБД используется для хранения копии метаданных) и таких функций, как система файлового потока SQL Server (где таблица базы данных файлов данных предоставляется ОС как обычный каталог, позволяющий как проводнику Windows получать доступ к данным, так и SQL-запросам к тем же данным).

Другие ОС имеют файловые системы RDBMS. В AS / 400 они были, хотя я никогда о них не узнал; Я помню, как странно это появилось в то время). Я думаю, что другие мэйнфрейм-системы имеют такой же подход.

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

Их объединение имеет свои преимущества, но до сих пор их было мало и достаточно далеко, чтобы движение росло медленно. Подумайте, как редко люди говорят: «Дайте мне 3-й столбец каждого счета, который я получил с 2010 года, и суммируйте их вместе» или «Не позволяйте мне удалить этот файл, пока я не удалю его из Excel». электронная таблица также. "

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

• Они намного проще. Это большая проблема при загрузке компьютера. Даже на Android , где у них есть СУБД для хранения, у них есть простые старые образы для управления процессом начальной загрузки.
  • Проще определить их ограничения. В неограниченном количестве машин RDBM обеспечивают достаточно много энергии. Однако в мире файловых систем существует множество ограничений, связанных с попытками быть быстрыми при непосредственном размещении поверх вращающегося диска. Труднее доказать, что запрос СУБД не превышает этих ограничений, чем обеспечить те же гарантии для файловой системы.
• Они лучше обрабатывают иерархические структуры. Во многих случаях для людей все еще естественно хранить файлы в иерархической форме. В РСУБД это особый случай. Файловые системы оптимизируются для этого особого случая, а СУБД - нет.
• Надежность. Гораздо проще доказать, что два слоя работают независимо, чем доказать, что одна гигантская система работает идеально. RAID- массивы, надежные журналы во время сбоев питания и другие расширенные функции проще реализовать на уровне ниже уровня, где рассматриваются такие вещи, как ограничения ACID или внешних ключей.

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

По-видимому, существуют технологии, которые позволяют монтировать реляционные базы данных в качестве файловых систем, когда их использование оправдано. Oracle DBFS (файловая система базы данных) является примером. Этот фрагмент документации хорошо объясняет причину, стоящую за этим:

Файловая система базы данных (DBFS) использует возможности базы данных для хранения файлов и сильные стороны базы данных в эффективном управлении реляционными данными для реализации стандартного интерфейса файловой системы для файлов, хранящихся в базе данных. Благодаря этому интерфейсу хранение файлов в базе данных больше не ограничивается программами, специально написанными для использования, BLOBи CLOBпрограммными интерфейсами. Теперь к файлам в базе данных можно получить прозрачный доступ с помощью любой операционной системы (ОС), которая работает с файлами.

Решение предоставляет набор интерфейсов (клиенты командной строки, библиотеки кода) для данных больших объектов, которые хранятся в таблицах базы данных. Это можно использовать в операционных системах Windows и Linux (хотя, насколько я могу судить, уровень интеграции между ними различен)

Источник: docs.oracle.com

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

В Linux dbfs_clientтакже имеется интерфейс монтирования, который использует FUSEмодуль ядра Файловая система в пользовательском пространстве ( ) для реализации точки монтирования файловой системы, которая обеспечивает прозрачный доступ к файлам, хранящимся в базе данных, и не требует никаких изменений в ядре Linux. Он получает стандартные вызовы файловой системы от FUSEмодуля ядра и преобразует их в вызовы OCI для процедур PL / SQL в DBFS Content Store .

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

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

Итак ... почему ОС Windows / Linux не использует реляционные базы данных (RDBMS)? Это вопрос библейских пропорций, но краткий ответ таков: нет реальной выгоды от использования сложной структуры, такой как rdbms, в качестве файловой системы.

«Реляционный» - это рабочее слово в «Реляционной базе данных», и большая часть данных, хранящихся в файловой системе, не связана с другими данными. Файловые системы обычно реализуются как ограниченные базы данных, но не реляционные.