有很大的數據庫文件的sqlite的性能特點是什麼？

274

我知道，即使在支持sqlite的時候，即使它們被支持，sqlite也不能很好地運行（以前是在sqlite網站上有一條評論，指出如果你需要1GB以上的文件大小，你可能要考慮使用企業rdbms 。無法再找到它，可能與舊版本的sqlite有關）。有很大的數據庫文件的sqlite的性能特點是什麼？

但是，爲了我的目的，我想了解在考慮其他解決方案之前它有多糟糕。

我正在談論2GB以上的多千兆字節範圍內的sqlite數據文件。任何人有任何這方面的經驗？任何提示/想法？

來源

2009-04-24 Snazzer

使用線程（每個線程的連接）可能僅對閱讀有幫助 - http://stackoverflow.com/a/24029046/743263 – malkia 2014-06-04 04:32:33

掛接http://softwareengineering.stackexchange.com/q/332069/ 24257和https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature#How_to_Store_Your_Data – Pacerier 2017-01-30 12:18:52

2016年：我有一個5 GB的數據庫t帽子在SQLite上運行沒有問題。我在Postgres上安裝了完全相同的數據集。 SQLite在2.7 ms內運行一個複雜的查詢，2.5 ms內運行Postgres。我最終在Postgres上獲得了更容易的Regex訪問和更好的索引功能。但是我對SQLite留下了深刻印象，也可以使用它。 – Paulb 2017-04-06 10:57:19

200

所以我做了一些測試用於sqlite的非常大的文件，並得出了一些結論（至少對於我的具體應用）。

測試涉及單個表或多個表的單個sqlite文件。每個表格大約有8列，幾乎所有的整數和4個指數。

這個想法是插入足夠的數據，直到sqlite文件大約50GB。

單桌

我想多行插入到sqlite的文件只有一個表。當文件大約7GB（抱歉，我不能具體說明行數）插入時間太長。我估計我的測試插入我所有的數據需要24小時左右，但即使在48小時後也沒有完成。

這使我得出結論，單個非常大的sqlite表會存在插入問題，並且可能還有其他操作。

我想這並不奇怪，隨着表格變大，插入和更新所有的索引需要更長的時間。

多個表

然後我試圖通過時間在幾個表，分割數據，每天一個表。原始1表格的數據被分成〜700個表格。

這個設置沒有插入問題，隨着時間的推移它不需要更長的時間，因爲每天都會創建一個新表。

真空問題

正如i_like_caffeine指出，真空命令是一個問題越大源碼文件。隨着更多插入/刪除操作的完成，磁盤上文件的碎片將變得更糟，因此目標是定期進行VACUUM以優化文件並恢復文件空間。

但是，正如documentation所指出的那樣，數據庫的完整副本被做成真空，需要很長時間才能完成。所以，數據庫越小，這個操作就會結束得越快。

結論

對於我的具體應用，我可能會分裂出過幾個分貝文件中的數據，每天一個，以獲得最好的兩個真空性能和插入/刪除速度。

這使查詢變得複雜，但對我來說，能夠索引這麼多數據是值得的折衷。另外一個好處是我可以刪除整個數據庫文件來刪除一天的數據（這是我的應用程序的一個常見操作）。

我可能必須監視每個文件的表大小以及速度將成爲問題的時間。

太糟糕了，除了auto vacuum之外似乎沒有增量真空方法。我無法使用它，因爲我的真空目標是對文件進行碎片整理（文件空間不是什麼大問題），而真空吸塵器不能做到這一點。事實上，文檔指出它可能會導致分裂更糟糕，所以我不得不求助於對文件進行全面的真空處理。

來源

2009-05-01 15:25:32 Snazzer

非常有用的信息。純粹的推測，但我不知道是否可以使用新的備份api來創建數據庫的非零碎版本，並避免需要運行VACUUM。 – eodonohoe 2009-05-03 16:36:35

+19

我很好奇，是否有交易中的所有插入？ – 2009-05-13 23:18:54

是的，每次交易的批量消息都是10000次。 – Snazzer 2009-05-14 15:17:16

我認爲主要的投訴sqlite的比例是：

單進程寫入。
沒有鏡像。
不復制。

來源

2009-04-24 01:29:36 Unknown

我已經創建了3.5GB大小的SQLite數據庫，沒有明顯的性能問題。如果我沒有記錯，我認爲SQLite2可能有一些下限，但我不認爲SQLite3有任何這樣的問題。

根據SQLite Limits頁面，每個數據庫頁面的最大大小爲32K。數據庫中的最大頁面數爲1024^3。所以我的數學計算出來的最大尺寸是32TB。我認爲在命中SQLite之前你會達到文件系統的限制！

來源

2009-04-24 14:46:10

根據您正在執行的操作，嘗試在8G sqlite數據庫中刪除3000行，它需要足夠的時間來沖泡法式印刷機，lol – benjaminz 2017-06-28 15:28:05

我在使用vacuum命令時遇到了大型sqlite文件的問題。

我還沒有嘗試過auto_vacuum功能。如果您希望經常更新和刪除數據，那麼這值得關注。

來源

2009-04-30 20:12:13 eodonohoe

在SQLite文檔中曾經有一個語句，數據庫文件的實際大小限制是幾十GB：s。這主要是由於SQLite在開始事務時需要「分配髒頁面的位圖」。因此數據庫中的每個MB需要256字節的RAM。插入50 GB的DB文件需要大量（2^8）*（2^10）= 2^18 = 256 MB的RAM。

但是從最近版本的SQLite開始，這已不再需要。閱讀更多here。

來源

2009-05-16 19:00:43

大部分花費48小時以上的原因是因爲您的索引。這是令人難以置信的速度更快：

1 - 刪除所有索引 2 - 是否所有刀片 3 - 創建索引再次

來源

2010-05-28 14:22:47 user352992

131

我們+在我們的平臺上使用50 GB的DBS。沒有抱怨很好。確保你做的一切都正確！你在使用預定義的語句嗎？ * SQLITE 3.7。3個

交易
前發言

應用這些設置（在創建數據庫後右）

PRAGMA main.page_size = 4096; 
PRAGMA main.cache_size=10000; 
PRAGMA main.locking_mode=EXCLUSIVE; 
PRAGMA main.synchronous=NORMAL; 
PRAGMA main.journal_mode=WAL; 
PRAGMA main.cache_size=5000;

希望這會幫助別人，偉大工程，這裏

來源

2011-06-30 11:21:47 Alex

我有一個7GB的SQLite數據庫。使用內部聯接執行特定查詢需要2.6s 爲了加快速度，我嘗試添加索引。根據我添加的索引，有時候查詢會下降到0.1s，有時會上升到7s。我想在我的情況下，問題是，如果一列是高度重複的，然後添加一個索引會降低性能:(

來源

2011-07-15 08:29:22

除了一般的建議：

DROP INDEX批量插入
批量插入在大宗交易/更新。
調整你的緩存/禁用日誌/ w的編譯指示。
使用一個64位機（以便能夠使用大量的緩存™的）。
[2014年7月增加]使用common table expression (CTE)而不是運行多個SQL查詢！需要SQLite版本3.8.3。

我已經學會從我的經驗SQLite3的如下：

對於最大插入速度，不使用模式與任何列約束。（~~根據需要稍後更改表格~~不能使用ALTER TABLE添加約束）。
優化您的模式以存儲您所需的內容。有時候這意味着在插入數據庫之前分解表格和/或甚至壓縮/轉換數據。一個很好的例子是將IP地址存儲爲（長）整數。
每個db文件一個表 - 最小化鎖爭用。（如果你想有一個連接對象使用附加數據庫。
的SQLite可以存儲不同類型在同一列（動態類型的數據），用它來你的優勢。

問題/評論歡迎。;-)

來源

2012-01-17 00:53:36

有很大的數據庫文件的sqlite的性能特點是什麼？

回答

相關問題