speed - what are appropriate uses for sqlite database




具有非常大的數據庫文件的sqlite的性能特點是什麼? (6)

以前在SQLite文檔中有一個聲明,數據庫文件的實際大小限制是幾十GB:s。 這主要是由於SQLite在開始事務時需要“分配臟頁面的位圖”。 因此數據庫中的每個MB需要256字節的RAM。 插入50 GB的DB文件需要大量(2 ^ 8)*(2 ^ 10)= 2 ^ 18 = 256 MB的RAM。

但就最近版本的SQLite而言,這已不再需要。 here閱讀更多。

我知道,sqlite在超大型數據庫文件中表現不佳,即使它們被支持(曾經有人對sqlite網站發表評論,指出如果你需要大於1GB的文件大小,你可能要考慮使用企業rdbms。再也找不到了,可能與舊版本的sqlite有關)。

然而,為了我的目的,我想在考慮其他解決方案之前了解它的真實性有多糟糕。

我正在談論2GB以上的多吉字節範圍內的sqlite數據文件。 有人對此有經驗嗎? 任何提示/想法?


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

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


我們在我們的平台上使用50 GB +的DBS。 沒有抱怨很好。 確保你做的一切都正確! 你在使用預定義的語句嗎? * SQLITE 3.7.3

  1. 交易
  2. 預先聲明
  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;
    

希望這會幫助別人,在這里工作很好


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

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


我認為關於sqlite縮放的主要抱怨是:

  1. 單進程寫入。
  2. 沒有鏡像。
  3. 沒有復制。

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

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

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

單桌

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

這導致我得出結論:單個非常大的sqlite表會存在插入問題,可能還有其他操作。

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

多個表

然後,我嘗試將數據按時間分成多個表格,每天一個表格。 原始1表格的數據被分成〜700個表格。

這種設置在插入時沒有問題,隨著時間的推移它不需要更長的時間,因為每天都創建一個新表。

真空問題

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

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

結論

對於我的具體應用,我可能會將數據分成幾個db文件,每天一個,以獲得最佳的真空性能和插入/刪除速度。

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

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

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





sqlite