SQLite作爲低流量站點的生產數據庫？

我正在考慮使用SQLite作爲一個網站的生產數據庫，可能會收到20個同時在線的用戶，但可能會有很多倍的高峯（因爲該網站可以在開放的互聯網上訪問，總是有人可能會在某處發佈鏈接，可能會將許多人一次性發送到網站）。SQLite作爲低流量站點的生產數據庫？

SQLite是否有可能？

我知道這不是一個理想的生產場景。我只問這是否屬於現實可能性的範疇。

來源

2009-05-26 carson welsh

SQLite不支持任何種類的併發，因此您可能在生產網站上運行它時遇到問題。如果你正在尋找一個'更輕'的數據庫，可能考慮嘗試一個像CouchDB這樣的當代對象文檔存儲。

通過一切手段繼續針對SQLlite進行開發，並且您最初可能很好地使用它。如果你發現你的應用程序擁有更多的用戶，那麼你會想轉換到postgres或mysql。

SQLlite筆者解決了這個on the website：

SQLite的通常會低到中等流量的網站（這是說，所有網站的99.9％），工作帶來極大的數據庫引擎。 SQLite可以處理的網絡流量的大小，當然取決於網站使用其數據庫的程度。一般來說，任何每天點擊次數少於100K的站點應該可以很好地使用SQLite。 100K點擊/日數是一個保守的估計，而不是一個硬性上限。 SQLite已被證明可以處理10倍的流量。

SQLite通常會正常工作，因爲數據庫後端到網站。但是如果你的網站如此繁忙，以至於你想將數據庫組件拆分到不同的機器上，那麼你絕對應該考慮使用企業級客戶機/服務器數據庫引擎而不是SQLite。

所以我認爲它的長短之處在於，如果它不適合你，那麼無論如何轉換到企業級數據庫都是相當微不足道的。但是，請注意您的架構，並考慮到增長和效率來設計您的數據庫。

這裏的a thread有一些關於使用SQLite生產Web應用程序的更多獨立評論。這聽起來像它已被用於一些混合的結果。

編輯（2014）：

由於這個答案被張貼，SQLite的現在擁有multi-threaded mode和write ahead logging mode這可能會影響您的它的適宜性評價中低流量的網站。

Charles Leifer已經寫了關於SQLite的WAL（預寫日誌）功能的a blog post以及關於適當的用例的一些深思熟慮的意見。

來源

2009-05-26 22:37:51

速度問題？但是，如果用戶太少，我不知道即使它不允許併發，它是否真的存在問題。（我只對關係數據庫感興趣） – 2009-05-26 22:40:51

有趣的報價。太糟糕了，它不是來自一個比Sqlite自己的作者更獨立的來源。我寧願看到一些外部驗證。 – 2009-05-26 22:50:45

我認爲這主要取決於讀寫比例。如果它主要是從數據庫中讀取的，那麼你可能沒問題。 SQLite中的多用戶寫入可能會成爲一個問題，因爲它會鎖定數據庫。

來源

2009-05-26 22:35:07

你是說如果有兩次同時寫入的嘗試，它會鎖定，直到一個完成，然後讓另一個完成？這對於數據完整性聽起來不是一個問題，而是關於速度的問題。鑑於交通流量低，這可能是可以容忍的。 – 2009-05-26 22:38:24

它不會阻塞但返回SQLITE_BUSY。由應用決定如何從那裏繼續，例如稍等片刻，再試一次或放棄並返回錯誤。 – laalto 2009-05-27 06:46:15

此外，在沃爾瑪模式下（提前寫入日誌記錄），如果有人仍然感興趣，sqlite會變得更加高效。 – infocyde 2017-11-11 00:06:05

取決於網站的使用情況。如果大部分時間只是讀取數據，則幾乎可以使用任何數據庫中的任何內容，並在應用程序中緩存數據以實現良好性能。

來源

2009-05-26 22:37:56 Badaro

我們經常使用SQLite作爲內部數據庫;員工目錄，我們的事件日曆和其他Intranet服務都在輕量級數據庫上運行。在mySQL這樣的「真實」數據庫上執行這些應用程序時，運行這些應用程序將會是一個重大的矯枉過正。當考慮到他們在單箇中檔計算機上與其他4臺虛擬機一起運行時尤其如此。

在某一時刻，我們有一個面向外部的網站在sqlite數據庫上運行數月，只需要一次重啓。顯然，它的流量非常低，但是它的功能很好。

來源

2009-05-26 23:30:26 Soviut

我使用它在一個非常低的流量的Web服務器（這是一個基因組數據庫），我沒有任何問題。但是隻有SELECT語句，沒有寫入涉及到的數據庫。

來源

2009-07-13 22:15:13 BlogueroConnor

人們談論併發問題，但sqlite有一種方法來緩存傳入的請求，讓他們等待一段時間。它不會立即超時。

我已閱讀有關默認超時設置的事情開始零，這意味着它立即超時，這是無稽之談。也許人們沒有調整這個設置？

來源

2010-07-03 19:38:34

要添加一個已經輝煌的答案：因爲在這種情況下您正在使用無服務器解決方案，所以您可以告別複製或任何類型的數據庫水平縮放以及其他高級選項。如果你有多個用戶更新相同的信息塊，這也不是最好的選擇。如果將來要分割數據庫，則必須遷移數據並移至其他位置。另外，如果你有一個負載均衡器和涉及多個系統，如果使用sqlite將很難保持數據中心性。這些只是不推薦的一些原因。它非常適合小型項目，並且非常適合開發。

來源

2014-01-18 17:11:23 radtek

我們在環境中遇到了類似的選項絕對沒有寫入，我們選擇使用SQLite。

見我blog post關於這個問題：

好了，主要的假設，這使得該解決方案在理論上可能的是，我們的SQLite數據庫完全是隻讀的。我們的服務器代碼不應該改變它。這將解決任何鎖定問題，因爲沒有讀鎖。我們可以在互聯網上找到任何地方說，當沒有寫入時，在高吞吐量讀取SQLite時出現問題 - 這可能是可能的！

來源

2014-10-20 06:30:26

SQLite website的小節選說了這一切。

是對數據通過網絡從應用程序分開？→選擇 客戶機/服務器

許多併發作家呢？ →選擇客戶端/服務器

大數據？ →選擇客戶端/服務器

否則→選擇SQLite！

SQLite的「只是工程」。

來源

2015-05-12 00:46:59 nehemiah

看起來像排隊，你也可以避免使用SQLite的許多併發寫入問題。不是直接寫入sqlite數據庫，而是寫入一個隊列，然後依次以先進先出的方式將數據寫入sqlite數據庫。不知道如果你的應用程序到達了你需要的地方，如果這是值得寫的，或者只是移動到客戶端/服務器數據庫......但是一個想法。

來源

2015-06-11 01:47:26 infocyde

SQLite作爲低流量站點的生產數據庫？

回答

相關問題