Чому Windows / Linux не використовують реляційні бази даних (RDBMS)?


32

Чому Windows / Linux не використовують реляційні бази даних ( RDBMS )?

Я знаю, що вони використовують файлові системи для зберігання всіх даних, але ви не вважаєте, що більш ефективно використовувати бази даних, як ми використовуємо на веб-сайтах / веб-додатках?

Будь ласка, детальніше поясніть використання файлової системи над базою даних для зберігання.

Це не дублікат. Коли слід використовувати базу даних над розбором даних із текстового файлу? Я говорю лише в контекстах операційної системи, і це питання узагальнено.


32
Файлова система - це база даних.

20
Оскільки для впровадження баз даних необхідні файлові системи .
Кіліан Фот

16
Windows використовує базу даних, вона називається "Реєстр". Або ви маєте на увазі "реляційну базу даних"? Це вже інше питання.
Док Браун

6
@ gnasher729 Файлова система - це дуже особливий вид бази даних, і як така корисна лише для певних видів даних. Інші види даних краще обслуговуватись із різними видами баз даних (наприклад, реляційними).

6
@KilianFoth, не дуже. Ви можете записати на необроблений розділ диска (який не можна порівняти з файлом ОС).
Пол Дрейпер

Відповіді:


60

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

На останніх комп’ютерах, які все ще використовують спінінг- жорсткі диски , диск настільки повільний - відносно процесора або оперативної пам’яті - що додавання кількох програмних шарів не має значення. Технологія SSD може дещо змінити, і деякі файлові системи оптимізовані для SSD.

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

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

Файли мають дещо менші абстракції, ніж бази даних, тому їх можна легше реалізувати (як файлові системи та рівень VFS у ядрі Linux) та швидше використовувати. Зокрема, операції над файлами значно більш обмежені, ніж операції з базами даних. Насправді ви можете бачити файли або файлові системи як деякі дуже обмежені бази даних!

Ви можете розробити операційну систему без будь - яких файлів , але з яким - або іншим ортогональної інерційністю механізмом (наприклад , має кожен процес бути стійким, то ви все одно багато явно про зберігання, так як операційна система управляють постійними ресурсами). Це було зроблено в декількох академічних операційних системах (1) (а також на машинах Smalltalk і Lisp 1980-х років, якось в IBM System i , також AS / 400 , і в деяких іграшкових проектах, пов'язаних з osdev), але коли ви проектуєте свою ОС таким чином, ви не можете скористатися багатьма існуючими інструментами (наприклад, вам також потрібно зробити компілятор і ваш користувальницький інтерфейс з нуля, і це дуже багато роботи).

Зауважте, що операційній системі для мікрокенелей, можливо, не потрібні файли, які надаються шарами ядра, оскільки файлові системи - це лише сервери додатків (наприклад, Hurd- перекладачі, що працюють у користувальницькій країні). Подивіться також на підхід унікеру в сучасних MirageOS

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

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

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

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


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

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


9
Варто також зазначити, що деякі файлові системи насправді мають ряд функцій RDBMS. Наприклад, метадані файлів (особливо розширені метадані) у BeFS індексуються деревами B +, а менеджер файлів BeOS мав пошук у вигляді SQL-механізму пошуку, який шукав індексовані метадані для пошуку файлів.
greyfade

2
Я не наважуюся викладати їх у своїй відповіді, але обидва blog tunes.org та J.Pitrat можуть розширити ваші погляди на програмне забезпечення та операційні системи.
Базиль Старинкевич

4
@greyfade: файлова система - це об'єктна база даних. Жодна з файлових систем, про яку я знаю, не має можливості відповідати на реляційні запити (наприклад, файли з модним часом у певному діапазоні.) Ви повинні це зробити, запитуючи модний час усіх файлів і фільтруючи себе. Деякі файлові системи працюють пристойно, використовуючи їх безпосередньо як об’єктну базу даних (зберігають мільйони дуже малих файлів, де ім'я файлу є ключовим), але інші роблять нормально з таким навантаженням.
Пітер Кордес

3
@PeterCordes: BeFS це зробив. Оскільки всі метадані були індексованими B + деревом, він підтримував запити діапазону, підстановки, приєднання та інші цікаві речі. Я пам’ятаю, чуючи, що Microsoft робила те саме, що і в WinFS.
greyfade

4
PalmOS була однією досить основною ОС, яка не мала файлової системи. Натомість він мав реляційну базу даних, яка була реалізована безпосередньо на оперативну пам’ять / спалах (оригінальне обладнання не використовувало флеш-пам’ять, як iPhone сьогодні, але використовувало статичну оперативну пам’ять, що підтримується батареєю, як для оперативної пам'яті, так і для диска).
slebetman

23

Хоча це ґрунтується на думці, я думаю, що це просто ще один історичний артефакт. Ранні ОС використовували просту конструкцію файлової системи для продуктивності, яка була досить міцно пов'язана з характеристиками обладнання, доступного на той момент, і з тих пір це було так само. Важко змінити API для читання / запису старого файлу для більшої кількості API-інтерфейсів для запиту / вставки після їх встановлення.

Усі поточні файлові системи мають вимогу бути сумісними з цими старими API.

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

Інші ОС мають файлові системи RDBMS. AS / 400 мали раніше їх, хоча я ніколи про них не дізнався достатньо; Пам’ятаю, як дивно це тоді було). Я думаю, що в інших системах мейнфрейму такий же підхід.


1
Якщо пам'ять служить, ви можете думати про DB2 UDB в OS / 400 aka i5 / OS (тепер називається просто "IBM i"): publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzamb/…
Брайан Клайн

1
Так, було б чудово починати трансакцію / комутацію дозволів на файли, а не робити "знайти з -exec". Піднесення примітивної файлової системи низького рівня в адмініланд є випадковим і повинно йти шляхом програмування. "Файлову систему" як належну систему зберігання та керування метаданими bytestream (хоча інтерпретацію вмісту bytestream все ж слід залишити шарам програми, інакше виникнуть головні болі)? Так, ми хочемо!
Девід Тонхофер

12

Справжня причина - відсутність потреби в цьому. Накладання баз даних поверх файлів, а не їх об'єднання, обробляє переважну більшість ситуацій принаймні так само, як і об'єднане рішення зі значно зниженою складністю. У деяких ситуаціях, про які згадували інші, ми також розшаровували частини файлів поверх баз даних (наприклад, структури дозволів). У цьому випадку база даних, що керує цими дозволами, надзвичайно простіша, ніж комерційна RDBMS.

Є переваги їх об'єднання, але поки що їх було мало і досить далеко між тим, що рух повільно зростає. Подумайте, як рідко люди кажуть "Наведіть мені 3-й стовпець кожного рахунку-фактури, який я отримував з 2010 року, і підсумуйте їх разом", або "не дозволяйте мені видаляти цей файл, поки я не видалю його з Excel також ".

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

  • Вони набагато простіші. Це велика справа при завантаженні комп'ютера. Навіть на Android , де у них є RDBMS для зберігання, вони мають звичайні старі зображення для управління початковим процесом завантаження.
    • Простіше визначити їх обмеження. У необмеженій машині RDBM забезпечують досить багато енергії. Однак у світі файлової системи існує дуже багато обмежень, які випливають із спроби бути швидкою, коли безпосередньо накладається на вершину спінінг-диска. Важче довести, що запит RDBMS не перевищує цих обмежень, ніж це надання тих же гарантій для файлової системи.
  • Вони краще обробляють ієрархічні структури. У багатьох випадках люди все ще природно зберігати файли в ієрархічній формі. У RDBMSes це особливий випадок. Файлові системи оптимізуються для цього особливого випадку, RDBMS не роблять.
  • Надійність. Набагато простіше довести, що два шари працюють незалежно, ніж довести, що одна гігантська система працює бездоганно. RAID- масиви, незахищені журнали під час відключення живлення та інші розширені функції легше реалізувати в шарі нижче шару, що стосується таких речей, як ACID або обмеження зовнішніх ключів.

1
надійність: ви можете запустити БД поверх RAID так само, як ви можете запустити файлову систему на пристрої RAID, порівняно з використанням диска безпосередньо. Журнал потрібно проводити всередині файлової системи / БД (якщо ви замість цього не хочете забезпечити гарантії коректності, відключивши кешування запису, і ніколи не впорядковуючи введення-виведення, тобто syncрежим.) +1 для всіх інших ваших пунктів, наприклад. швидка герархічна ефективність, коли кількість матеріалів в одному піддіректорі не уповільнює продуктивність в іншому підрозділі. Якщо кожен редактор або файл не є іншою таблицею ...
Пітер Кордес

надійність: ОС IBM i серії розроблені таким чином, щоб бути надійнішими, ніж ви можете собі уявити, розроблені для використання в стилі мейнфреймів. Ієрархії існують лише через обмеження файлової системи, отже, MS хочуть пізніше шукати операції з БД на вершині існуючої файлової системи. Подивіться на gmail як на приклад, як можна мати ієрархію, не використовуючи ієрархії!
gbjbaanb

3

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

Мабуть, є технології, які дозволяють монтувати реляційні бази даних як файлові системи, коли їх використання виправдане. Приклад Oracle DBFS (файлова система бази даних) . Цей фрагмент із документації досить добре пояснює обґрунтування цього:

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

Рішення пропонує набір інтерфейсів (клієнти командного рядка, бібліотеки коду) для даних LOB, які зберігаються в таблицях баз даних. Це можна використовувати в операційних системах Windows та Linux (хоча, наскільки я можу сказати, рівень інтеграції залежить від них)

Компоненти Oracle DBFS

Джерело: docs.oracle.com

Згідно з документацією, файлову систему слід мати можливість прозоро використовувати в Linux

У Linux dbfs_clientтакож є інтерфейс кріплення, який використовує FUSEмодуль ядра Filesystem in User Space ( ) для реалізації точки монтування файлової системи, яка забезпечує прозорий доступ до файлів, що зберігаються в базі даних, і не потребує змін до ядра Linux. Він отримує стандартні дзвінки файлової системи від FUSEмодуля ядра та переводить їх у виклики OCI до процедур PL / SQL у сховищі вмісту DBFS .

Тому відповідь на ваше запитання полягає в тому, що загалом немає жодної причини, щоб операційна система використовувала реляційну базу даних як файлову систему (а у випадку основних компонентів ОС це насправді буде проблематично). У той же час це можна зробити, коли якась проблема викликає це.


2

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

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

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


Можливо, краще питання - чому додатки потребують баз даних, а не просто зберігати дані у файлах? Я ніколи не знайшов задовільної відповіді на це питання. Усі передбачувані переваги реляційної бази даних можна отримати за допомогою файлу sustem
Шрідхар Сарнобат
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.