文件數據庫與應用伺服器數據庫的並發性能和批量數據
我問了一個關於 Ripple 的數據庫實現的問題，並收到了這樣的回复：
波紋伺服器使用 SQLite 儲存結構化數據，使用可配置的“後端”儲存非結構化“批量”儲存。
結構化數據包含諸如交易受其影響的帳戶索引之類的內容。非結構化數據由散列索引的數據“塊”組成，這些數據構成網路歷史的一部分。
大容量儲存的首選後端目前是 Linux 平台上的 RocksDB。
這讓我覺得很奇怪，因為 Ripple 的結構允許開發人員對伺服器運營商提出幾乎任何他們希望的要求。換句話說，為什麼不使用數據庫伺服器，特別是 PostgreSQL？
我發現了 PostgreSQL 與 SQLite 的這個有趣的細分，以及這個解釋：
它分解為他們如何實現快照隔離。
SQLite 使用文件鎖定作為隔離事務的一種手段，只允許在所有讀取完成後寫入。
相比之下，Postgres 使用一種更複雜的方法，稱為多並發版本控制 (mvcc)，它允許多次寫入與多次讀取並行發生。
首先，大容量儲存的理想實現是否真的是使用文件數據庫？
其次，對於並發讀取和寫入，PostgreSQL 是否真的大大優於文件數據庫？
最後，當表的長度接近數十億行時，為了並發性能，文件數據庫還是 PostgreSQL 更勝一籌？
請假設這兩種選擇都經過了理想調整。
首先，大容量儲存的理想實現是否真的是使用平面文件數據庫？
如果您在談論 SQLite，它不是“平面文件數據庫”。當然，它是一個單文件數據庫，但它是高度結構化的.
其次，對於並發讀取和寫入，PostgreSQL 是否真的大大優於平面文件數據庫？
對於具有同時讀取和寫入的工作負載，PostgreSQL 通常會大大優於 SQLite，因為讀取器可以在寫入表的同時繼續進行。對於具有非平凡事務的多個並發讀取器和寫入器，沒有競爭。為了使這成為可能，PostgreSQL 必須至少將每個更改寫入兩次，然後再進行清理“真空”工作。
通常，您可以序列化許多短的讀寫事務，因此它們似乎執行得非常快，即使它們每個都在鎖定上等待一段時間。因此，對於瑣碎的讀取和寫入，即使有多個並發客戶端，SQLite 仍然可以做得很好，只要鎖定持續時間很短。對於長期交易，這是完全沒有希望的。
換句話說，為什麼不使用數據庫伺服器，特別是 PostgreSQL？
可能是因為設置和執行 SQLite 很簡單，所以嵌入應用程序更容易。
PostgreSQL 不支持程序內嵌入。雖然捆綁數據庫伺服器很容易，但它仍然是許多開發人員不想要的麻煩。升級 PostgreSQL 也是一件痛苦的事，因為文件格式會隨著每個主要版本的變化而變化，並且需要升級步驟——而 SQLite 的文件格式令人難以置信的向上和向下兼容。