Почему Windows / Linux не использует реляционные базы данных ( RDBMS )?
Я знаю, что они используют файловые системы для хранения всех данных, но не думаете ли вы, что более эффективно использовать базы данных, которые мы используем в веб-сайтах / веб-приложениях?
Пожалуйста, уточните использование файловой системы над базой данных для хранения.
Это не дубликат. Когда следует использовать базу данных предпочтительнее, чем анализировать данные из текстового файла? Я говорю только о контексте операционной системы, и этот вопрос обобщен.
Ответы:
Сегодня большинство систем управления базами данных (например, PostGreSQL , MongoDB и т. Д.) Внутренне хранят свои данные в файлах ОС (в прошлом некоторые СУБД использовали непосредственные разделы сырых дисков).
На недавних компьютерах, все еще использующих вращающиеся жесткие диски , диск настолько медленный - относительно ЦП или ОЗУ - что добавление нескольких слоев программного обеспечения не имеет значения. Технология SSD может немного изменить это, и некоторые файловые системы оптимизированы для SSD.
Файлы присутствуют в большинстве операционных систем в целом по историческим и социальным причинам (в частности, компиляторы C и большинство инструментов - редакторы, компоновщики - хотят файлы, поэтому возникает проблема с курицей и яйцами), а также потому, что существует множество очень хороших файлов. системные реализации.
Кстати, некоторые важные системные средства могут использовать базы данных. Например, в Linux PAM можно настроить на использование информации в базах данных (но на практике это редко делается). Кроме того, некоторые почтовые серверы могут хранить некоторые или большую часть своих данных в базах данных (например, Exim ).
Файлы представляют собой несколько более низкие абстракции, чем базы данных, поэтому их проще реализовать (как файловые системы и уровень VFS в ядре Linux) и быстрее использовать. В частности, операции с файлами гораздо более ограничены, чем с базами данных. Фактически, вы могли видеть файлы или файловые системы как некоторые очень ограниченные базы данных!
Вы можете разработать операционную систему без каких - либо файлов , но с каким - либо другим ортогональной инерционностью механизмом (например , имеющей каждый процесс быть стойким, то вы все равно много явно о хранении, так как операционная система управляют постоянными ресурсами). Это было сделано в нескольких академических операционных системах (1) (а также на машинах 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». электронная таблица также. "
Файловые системы имеют несколько преимуществ перед реляционными базами данных, которые поддерживают их работу:
источник
sync
Mode.) +1 для всех остальных ваших точек, особенно быстрая иерархическая производительность, при которой куча материала в одном подкаталоге не снижает производительность в другом подкаталоге. Если каждый каталог или файл не является отдельной таблицей ...Я думаю, что другие ответы предоставляют широкий спектр причин, почему операционные системы не полагаются на реляционные базы данных внутренне / исключительно, поэтому я просто поделюсь интересной информацией, на которую я однажды наткнулся.
По-видимому, существуют технологии, которые позволяют монтировать реляционные базы данных в качестве файловых систем, когда их использование оправдано. Oracle DBFS (файловая система базы данных) является примером. Этот фрагмент документации хорошо объясняет причину, стоящую за этим:
Решение предоставляет набор интерфейсов (клиенты командной строки, библиотеки кода) для данных больших объектов, которые хранятся в таблицах базы данных. Это можно использовать в операционных системах Windows и Linux (хотя, насколько я могу судить, уровень интеграции между ними различен)
Источник: docs.oracle.com
Согласно документации, файловая система должна быть прозрачной для Linux.
Следовательно, ответ на ваш вопрос заключается в том, что в общем случае у операционной системы нет причин использовать реляционную базу данных в качестве файловой системы (а в случае основных компонентов операционной системы это на самом деле будет проблематично). В то же время можно сделать это, когда какая-то проблема требует этого.
источник
Основная функция любой ОС - облегчить взаимодействие между приложениями, оборудованием и пользователями.
Итак ... почему ОС Windows / Linux не использует реляционные базы данных (RDBMS)? Это вопрос библейских пропорций, но краткий ответ таков: нет реальной выгоды от использования сложной структуры, такой как rdbms, в качестве файловой системы.
«Реляционный» - это рабочее слово в «Реляционной базе данных», и большая часть данных, хранящихся в файловой системе, не связана с другими данными. Файловые системы обычно реализуются как ограниченные базы данных, но не реляционные.
источник