1樓：liujunsong
這是個很好的問題。
如果要摳字眼的話，首先要定義問題裡面的第乙個檔案系統是乙個什麼概念。
一般的理解，這個檔案系統是指實現了類似作業系統檔案管理功能的檔案訪問介面。
可想而知，如果要在資料庫上直接全部實現這些，其工作量是相當驚人的。
這種情況下，在資料量比較小的時候，是沒有什麼問題的，資料庫本身提供blob clob，實際上就是在作業系統上包裝一下，變成乙個流傳遞給客戶端。把檔案內容放到資料庫裡面，最大的優點是可以保證資料檔案的安全性，可以直接使用資料庫的安全機制來保護這些資料。而劣勢則是速度和效率的損失，這個沒辦法，世界上的事情，總是有利有弊的。
作為資料庫廠商來說，最推崇這種方案，畢竟對他們是最有利的。但如果是使用的開源軟體，那麼架構師必須考慮資料全部放到資料庫裡面的資料安全問題，一旦資料庫檔案損壞丟失，有沒有合適的機制來進行恢復？如果沒有開源產品支援，就只能自己開發了，這就是選擇拋棄檔案系統全部自己玩，必然帶來的後期資料恢復的工作量和風險。
一般來說，作為風險厭惡型的技術選型，是不提倡把所有雞蛋放到乙個籃子裡面的，一旦資料庫崩潰，恢復的時間應當盡量短暫，而如果連檔案也存到資料庫裡面，恢復的時間就會變得很漫長，而且很容易出錯。
經歷過資料庫資料丟失損壞以後，對資料庫這東西是要有風險機制的，因此一般不建議把資料檔案存放到資料庫裡面去。
但有一種特殊情況，就是對資料的敏感性和安全性要求很高，要從邏輯上避免運維人員訪問到資料檔案，而強制要求只能通過資料庫來訪問，甚至資料檔案在資料庫內部也是經過加密的，這種剛性的需求就決定了只能使用資料庫來進行儲存，而由此帶來的風險和困難則通過其他技術手段來規避掉。
總而言之，檔案放資料庫裡面，可以大幅度提高資料檔案的安全性，因為運維人員是不可見的，但需要利用資料庫的安全機制，缺點是效能降低，複雜度增加。檔案放檔案系統裡面由作業系統管理，邏輯簡單，但運維存在洩密風險，管控要困難一些。
另外再說一下個人對使用mongodb來儲存檔案的看法。
使用mongodb來儲存檔案當然是可行的，gridfs，但這個方案也是存在風險的。第一，mongo存入檔案以後，如何保證這個檔案一定是有效的，可用的，這個需要額外寫程式去確認。第二，在mongo失敗崩潰以後，如何從備份中恢復，這個也會是乙個難點。
第三，使用mongo以後，由於mongo本身的安全機制很弱，如何細化使用者管理，避免誤操作帶來資料損失，是需要額外進行考慮的問題。
2樓：駿馬金龍
使用資料庫(特指關係型資料庫而非記憶體資料庫)時，效能基本上不可能比直接讀取、寫入塊裝置更快。
資料庫不是什麼終極大殺器，資料庫也只是用來存資料的，它是因為有了各種各樣的需求演變而來，不是效能的演變，而是需求的演變。每一步演變，效能是有下降趨勢的(當然也會有各種優化手段)：
最原始的資料庫就是平面資料庫，也就是文字檔案(熟悉文字處理工具的人應該都深有體會)。比如CSV格式的文字檔案就是比較古老但至今仍廣為使用的一種資料儲存方式。
平面資料庫只適合簡單的資料處理需求，一旦需求複雜，處理起來極為麻煩
但如果只是追加式寫入資料，這種方式效率最高
從平面資料庫進一步發展而來的資料庫是dbm。相當於儲存在檔案中的hash結構：元資料區存放包含索引(即hash的key)、資料偏移等的元資料(有些dbm還會帶快取功能)，資料區存放真正的資料。
這種元資料和實際資料分離，且有索引、有快取的儲存方式，應該算是最高效的訪問方式檔案系統採用的是類似dbm的儲存方案
dbm的思想才是在塊裝置上訪問資料的效能銀彈
再進一步發展才是關係型資料庫，關係型資料庫的儲存方式變得更加複雜，資料庫在作業系統的基礎上再進一步由自己管理資料在檔案中的訪問方式。
學關係型資料庫的第一節課，書裡都會解釋關係型和結構化，但基本上沒人會去理解關係型和結構化這兩個概念，但這兩個術語卻是對關係型資料庫最本質的描述。
dbm等儲存方案是有缺點的，其中一方面就是不方便儲存各種各樣的資料(比如如何儲存空值，如何儲存時間資料等)，這才演變出了關係型、結構化的資料庫。
所謂結構化：資料庫自解釋它所儲存的資料型別，每條資料中的每個字段根據它們的資料型別，它們的空間位置是規劃好的。總的來說，就是將包含各種亂七八糟的一條資料結構化存放了，將多條亂七八糟的資料也結構化存放在乙個表中了。
所謂關係型：資料庫裡的資料是可以關聯訪問的。外來鍵的存在就是關聯的一種體現，可以對不同位置的資料進行join查詢，也是關聯的一種體現。
從本質上來說，資料庫只是用來訪問資料的。平面資料庫和dbm也可以是結構化和關係型的，只不過它們的結構化和關係型需要使用者自己去維護，而不是像關係型資料庫一樣由資料庫系統維護。
例如，CSV格式的檔案本身是結構化的(結構化能力很弱)，聯合處理兩個或多個CSV檔案(從b.txt中找出a.txt中不存在的行)則是關係型的。
因此，關係型資料庫只是一種更健壯、更安全、功能更豐富、使用者使用起來更簡單(真的簡單嗎？)的資料訪問方案。但，不是效能最高的(相反，效能反而是比較差的，比如寫100W條資料到檔案或dbm，速度遠高於寫入資料庫)。
所以，關係型資料庫適合複雜的資料訪問需求，如果是簡單的訪問需求，使用dbm更佳。
資料庫和檔案系統是什麼關係？
榮記 早期電腦程式通過檔案系統的程式設計介面管理資料有很多不方便的地方，比如資料很容易冗餘 資料格式和讀寫的應用程式繫結緊密，不方便共享 需要程式自己保證資料的一致性等等。而當時很多資料都是屬於有關係的資料，所以在上層做一層關聯式資料庫概念的抽象封裝，通過統一標準的資料庫介面訪問資料。關聯式資料庫提...
分布式檔案系統上可不可以跑資料庫？
跑肯定是能跑的，但其實不太適合直接跑RocksDB，效能會受限。RocksDB使用了LSM Tree，其優勢在於把隨機寫轉化成了連續寫，這對於本地的SSD盤是很有優勢的，在大量寫入的場景下比傳統的B Tree效能要好。而在分布式檔案系統中，隨機寫並不比連續寫要慢，甚至要比連續寫要快。這是因為分布式檔...
資料庫管理系統dbms和資料庫dbs是什麼關係？
李宇明 一般的劃分 DB，即database，一般指乙個具體的資料集 庫 可以理解成database instance 如果是關係模型的話，就是一堆資料表 索引和檢視啥的。但是一般在寫作時或者交流時，database也可指下面兩個詞的含義，所以它的具體含義還得看上下文 DBMS，即database ...