這種關於具有集中儲存的分佈式數據庫伺服器的想法是否可行？
我經常使用 SQLite 在公司中創建簡單的程序。數據庫放置在文件伺服器上。只要同時處理數據庫的使用者不超過 50 個（儘管取決於它是讀取還是寫入），它就可以正常工作。一旦超過這個數量，如果伺服器上有很多並發寫入，他們會注意到速度變慢，因為很多時間都花在了鎖上，而且沒有像記憶體這樣的東西，因為沒有數據庫伺服器。
不需要數據庫伺服器的好處是，設置公司 Wiki 或類似內容的時間可以從幾個月減少到幾天。這通常需要幾個月的時間，因為某些 IT 部門需要訂購伺服器，並且需要符合公司政策和安全規則，並且需要放置在外包的伺服器託管設施上，這會搞砸並將其放置在錯誤的位置等等等等
因此，我想到了一個創建分佈式數據庫伺服器的想法。該過程如下：公司電腦上的使用者在 Wiki 頁面（使用此數據庫作為其後端）上編輯某些內容，為此他讀取本地硬碟上的文件，該文件說明最後一台台式電腦的 IP 地址成為數據庫伺服器。然後，他嘗試通過 TCP/IP 直接聯繫這台電腦。如果它沒有回答，那麼他將讀取文件伺服器上的文件，說明最後一台台式電腦的 IP 地址作為數據庫伺服器。如果這台伺服器也沒有應答，他自己的台式電腦將成為數據庫伺服器並在同一文件中註冊其 IP 地址。然後就可以執行SQL更新語句了，其他桌面電腦就可以直接連接到他了。
這種架構的要點是，負載越高，它的功能就越好，因為每台台式電腦總是知道數據庫伺服器的 IP 地址。此外，使用這種設置，我相信放置在文件伺服器上的數據庫可以為數百台台式電腦提供服務，而不是目前的 50 台左右。我也不相信已經成為數據庫伺服器的單台台式電腦上的負載會很明顯，因為在這個台式機上不會有硬碟操作，只有在文件伺服器上。
這個想法可行嗎？它已經存在了嗎？什麼樣的數據庫可以支持這樣的架構？
編輯：我應該指出，這個想法並不漂亮、穩定、最佳實踐，或者我真正引以為豪的東西。我仍然對可行性感興趣的原因是我的一些客戶是銀行，並且獲得訪問數據庫所涉及的官僚機構是巨大的。通常此類項目的項目發起人需要高於副總裁級別，因為他們非常擔心訪問伺服器的安全問題。不用說，這意味著建立一個 Wiki 需要做很多工作。稍後，如果 Wiki 被證明是成功的，它當然應該被遷移到適當的數據庫伺服器上。
Edit2：這個想法的原因是當數據庫放置在文件伺服器上時，使用 SQLite 時降低 Writer Starvation 的風險。此問題在此處的第 5.1 節中進行了描述。使用台式電腦記憶體訪問最多的資訊（即 Wiki 頁面），意味著文件伺服器上的工作量將大大減少。這應該再次改善使用者體驗。你真的認為我對這個想法還有很長的路要走嗎？
如果您在不同的數據庫上分區（或定位）您的讀寫操作，您實際上可以建構一個良好的分佈式數據庫環境。我們做這樣的工作，訣竅很簡單。您在文件伺服器上擁有主數據庫，並將所有寫入作為目標。您在每個使用者的電腦上都有一個數據庫的本地副本，並且您將讀取目標定位到它。您現在還需要主數據庫和本地數據庫之間的同步機制。這可以通過多種方式完成。一種方法是在主數據庫中有一個“增量”表。此增量表將包含已在主數據庫中應用的事務。每當使用者的應用程序執行讀取或寫入操作時，首先在本地檢查和更新主伺服器上的增量。只有增量中尚未應用的事務（可以根據時間戳檢查）需要應用。您甚至可以讓後台程序連續執行此操作。當刷新時，此增量可能是每日增量（或每週增量）。如果使用者一周左右沒有登錄，您只需將整個數據庫複製到使用者的電腦上。擁有本地副本的優勢在於，使用者即使在離線時也可以查詢內容，而且——不管你信不信——即使你線上更新內容，這也相當快。