Сьогодні більшість систем управління базами даних (наприклад, 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 )