Perché Windows / Linux non utilizzano database relazionali (RDBMS)?

Perché Windows / Linux non utilizzano database relazionali ( RDBMS )?

So che usano i file system per archiviare tutti i dati ma non pensi che sia più efficiente usare database come quelli che usiamo nei siti Web / app Web?

Si prega di elaborare l'uso di un file system su un database per l'archiviazione.

Questo non è un duplicato di Quando si dovrebbe preferire l'uso del database rispetto all'analisi dei dati da un file di testo? Sto parlando in termini di soli contesti del sistema operativo e questa domanda è generalizzata.

Oggi, la maggior parte dei sistemi di gestione dei database (ad esempio PostGreSQL , MongoDB , ecc ...) conserva internamente i propri dati all'interno dei file del sistema operativo (in passato alcuni DBMS utilizzavano direttamente le partizioni del disco non elaborato).

^{Sui computer recenti che utilizzano ancora dischi rigidi in rotazione , il disco è così lento - rispetto alla CPU o alla RAM - che l'aggiunta di alcuni livelli software non è rilevante. La tecnologia SSD potrebbe cambiare un po 'questo e alcuni file system sono ottimizzati per gli SSD.}

I file sono presenti nella maggior parte dei sistemi operativi in ​​generale per motivi storici e sociali (in particolare, compilatori C e la maggior parte degli strumenti - editor, linker - vogliono file, quindi c'è un problema di pollo e uovo) e perché ci sono molti file molto buoni implementazioni di sistema .

A proposito, alcune strutture di sistema essenziali possono utilizzare database. Ad esempio su Linux PAM può essere configurato per utilizzare le informazioni nei database (ma ciò avviene raramente in pratica). Inoltre, alcuni server di posta possono archiviare alcuni o la maggior parte dei loro dati in database (ad esempio Exim ).

I file sono astrazioni leggermente inferiori rispetto ai database, quindi possono essere più facili da implementare (come i file system e il livello VFS nel kernel Linux) e più veloci da usare. In particolare, le operazioni sui file sono molto più limitate di quelle sui database. In effetti, potresti vedere file o file system come alcuni database molto limitati!

Potresti progettare un sistema operativo senza alcun file , ma con qualche altro macchinario di persistenza ortogonale (ad es. Avere ogni processo persistente, quindi non ti preoccupi molto esplicitamente della memorizzazione, poiché il sistema operativo gestisce risorse persistenti). Ciò è stato fatto in diversi sistemi operativi accademici ⁽¹⁾ (e anche nelle macchine Smalltalk e Lisp degli anni '80, in qualche modo nell'IBM System i , noto anche come AS / 400 , e in alcuni progetti giocattolo collegati da osdev), ma quando si progetta il sistema operativo in questo modo, non è possibile sfruttare molti strumenti esistenti (ad esempio, è necessario anche rendere il compilatore e l'interfaccia utente da zero, e questo richiede molto lavoro).

Si noti che i sistemi operativi microkernel potrebbero non aver bisogno di file forniti dai livelli del kernel poiché i file system sono solo server delle applicazioni (ad esempio traduttori Hurd in esecuzione nell'area utente). Guarda anche l' approccio unikernel nell'attuale MirageOS

Linux (e probabilmente Windows, che ha preso la maggior parte della sua ispirazione da VMS e Unix ) ha bisogno dei file per funzionare. Per lo meno, il programma init (il primo programma avviato dal kernel) deve essere un eseguibile memorizzato in un file (spesso /sbin/init, ma potrebbe essere systemd in questi giorni), e (quasi) tutti gli altri programmi vengono avviati con execve (2 ) syscall quindi deve essere archiviato in un file. Tuttavia, FUSE ti consente di fornire una semantica simile a un file a cose non file.

Si noti inoltre che su Linux (e forse anche su Windows, che non conosco e non ho mai usato) sqlite è una libreria che gestisce alcuni database SQL in un file e fornisce un'API per questo. È risaputo che Android (una variante Linux) utilizza molti file sqlite (ma ha ancora un file system simile a POSIX).

Leggi anche sul checkpoint dell'applicazione (che, su molti sistemi operativi attuali, è implementato per scrivere lo stato del processo in file). Spinto all'estremo, tale approccio non ha bisogno di scrivere manualmente i file dell'applicazione (ma solo di mantenere l'intero stato del processo utilizzando il macchinario di checkpoint).

In realtà, la domanda interessante è perché gli attuali sistemi operativi usano ancora i file, e la risposta è legacy e ragioni economiche e culturali (purtroppo, la maggior parte dei linguaggi di programmazione e delle biblioteche oggi vogliono ancora i file).

Nota 1: i sistemi operativi accademici persistenti includono Lisaac e Grasshopper , ma questi progetti accademici sembrano essere inattivi. Guarda anche su http://tunes.org/ ; è inattivo, ma ha avuto molte discussioni su tali argomenti.

Nota 2: la nozione di file è cambiata ampiamente nel tempo (guarda questa risposta sulle mie prime esperienze di programmazione): il primo MSDOS su PC IBM degli anni '80 (nessuna directory!), Il VMS -su Vaxen del 1978 - (aveva entrambi record fissi file e file sequenziali, con un sistema di versioning primitivo), i mainframe degli anni '70 ( IBM / 370 con OS / VS2 MVS ) avevano una nozione molto diversa di file e file system (in particolare perché a loro tempo il rapporto tra tempo di accesso al disco rigido e il tempo di accesso alla memoria core era di qualche migliaio, quindi a quel tempo il disco era relativamente più veloce di oggi, anche se i dischi di oggi lo sono assolutamentepiù veloce rispetto al secolo precedente, oggi il rapporto velocità CPU / disco è di circa un milione; ma ora abbiamo SSD). Inoltre, i file sono meno (o addirittura non utili) quando la memoria è persistente (come nel caso del tamburo magnetico CAB500 , anni '60; o dei computer futuri che utilizzano MRAM )

Sebbene sia basato sull'opinione, penso che sia solo un altro artefatto storico. I primi sistemi operativi utilizzavano un semplice design di file system per prestazioni che erano ragionevolmente fortemente legate alle caratteristiche dell'hardware disponibile al momento, ed è stato lo stesso da allora. È difficile modificare le vecchie API di lettura / scrittura del file per ulteriori query transazionali / inserire API una volta stabilite.

Tutti i file system correnti devono essere retrocompatibili con queste vecchie API.

Microsoft ha pensato di sostituire il file system con uno basato su RDBMS , nello sviluppo di Longhorn . Questa è stata una modifica troppo grande per loro, ma vedi che i loro sforzi continuano sotto forma di Ricerca di Windows (dove un RDBMS viene utilizzato per archiviare una copia di metadati) e funzionalità come il sistema Filestream di SQL Server (dove un la tabella del database dei dati dei file è esposta al sistema operativo come una normale directory che consente sia l' accesso ai dati a Esplora risorse che le query SQL degli stessi dati).

Altri sistemi operativi hanno filesystem RDBMS. Gli AS / 400 ne erano abituati, anche se non ho mai imparato abbastanza su di loro; Ricordo quanto appariva strano in quel momento). Penso che altri sistemi mainframe abbiano lo stesso tipo di approccio.

La vera ragione è la mancanza di necessità. La stratificazione di database in cima ai file, piuttosto che unirli, gestisce almeno la stragrande maggioranza delle situazioni, nonché una soluzione unita con una complessità sostanzialmente ridotta. In alcune situazioni menzionate da altri, abbiamo anche stratificato parti di file in cima ai database (come le strutture delle autorizzazioni). In tal caso, il database che gestisce tali autorizzazioni è notevolmente più semplice di un RDBMS commerciale.

Ci sono vantaggi nel fonderli, ma finora quelli sono stati pochi e abbastanza lontani tra loro che il movimento sta crescendo lentamente. Considera quanto è raro che la gente dica "Dammi la terza colonna di ogni fattura che ho ricevuto dal 2010 e sommali insieme" o "non lasciarmi eliminare questo file finché non lo rimuovo da Excel anche foglio di calcolo ".

I file system presentano alcuni vantaggi rispetto ai database relazionali che li mantengono attivi:

• Sono molto più semplici. Questo è un grosso problema quando si avvia un computer. Anche su Android , dove hanno un RDBMS per l'archiviazione, hanno semplici immagini vecchie per gestire il processo iniziale di bootloading.
  • È più facile definirne i limiti. In una macchina illimitata, gli RDBM forniscono molta energia. Tuttavia, nel mondo del file system, ci sono molte limitazioni che derivano dal tentativo di essere veloci quando sono direttamente a strati su un disco rotante. È più difficile dimostrare che una query RDBMS non superi tali limiti piuttosto che fornire le stesse garanzie per un file system.
• Gestiscono meglio le strutture gerarchiche. In molti casi, è ancora naturale per le persone archiviare i file in una forma gerarchica. In RDBMS, questo è un caso speciale. I file system si ottimizzano per quel caso speciale, gli RDBMS no.
• Affidabilità. È molto più facile dimostrare che due strati funzionano in modo indipendente piuttosto che dimostrare che un sistema gigante funziona perfettamente. Array RAID , riviste a prova di errore in periodi di interruzione dell'alimentazione e altre funzionalità avanzate sono più facili da implementare in un livello sotto il livello che si occupa di problemi quali ACID o vincoli di chiave esterna.

Penso che le altre risposte forniscano una vasta gamma di ragioni per cui i sistemi operativi non si basano su database relazionali internamente / esclusivamente, quindi condividerò solo un'informazione interessante su cui mi sono imbattuto una volta.

Apparentemente, ci sono tecnologie che ti permettono di montare database relazionali come file system quando il loro uso è giustificato. Oracle DBFS (Database File System) è un esempio. Questo frammento della documentazione spiega abbastanza bene la logica alla base:

Database File System (DBFS) sfrutta le funzionalità del database per archiviare i file e i punti di forza del database nella gestione efficiente dei dati relazionali, per implementare un'interfaccia di file system standard per i file memorizzati nel database. Con questa interfaccia, l'archiviazione dei file nel database non è più limitata ai programmi scritti appositamente per l'uso BLOBe alle CLOBinterfacce programmatiche. Ora è possibile accedere in modo trasparente ai file nel database utilizzando qualsiasi programma del sistema operativo (OS) che agisce sui file.

La soluzione fornisce una serie di interfacce (client della riga di comando, librerie di codici) per i dati LOB archiviati nelle tabelle del database. Questo può essere utilizzato su sistemi operativi Windows e Linux (anche se per quanto ne so, il livello di integrazione varia tra di loro)

Fonte: docs.oracle.com

Secondo la documentazione, il file system dovrebbe essere possibile utilizzare in modo trasparente su Linux

Su Linux, dbfs_clientha anche un'interfaccia mount che utilizza il FUSEmodulo del kernel Filesystem in User Space ( ) per implementare un mount point del file system che fornisce un accesso trasparente ai file memorizzati nel database e non richiede modifiche al kernel Linux. Riceve le chiamate di file system standard dal FUSEmodulo del kernel e le traduce in chiamate OCI nelle procedure PL / SQL nel Content Store DBFS .

Pertanto, la risposta alla tua domanda è che, in generale, non c'è motivo per un sistema operativo di utilizzare un database relazionale come file system (e nel caso dei componenti principali di un sistema operativo, ciò sarebbe effettivamente problematico). Allo stesso tempo è possibile che uno lo faccia quando qualche problema lo richiede.

La funzione principale di qualsiasi sistema operativo è facilitare le interazioni tra applicazioni, hardware e utenti.

Quindi ... perché il sistema operativo Windows / Linux non utilizza i database relazionali (RDBMS)? Questa è una domanda di proporzioni bibliche, ma la risposta breve è: non c'è alcun vantaggio reale da ottenere usando una struttura complessa come un rdbms come file system.

"Relazionale" è la parola chiave in "Database relazionale" e la maggior parte dei dati memorizzati in un file system non è correlata ad altri dati. I file system sono generalmente implementati come database limitati, ma non come database relazionali.