SQLite單表4億訂單，大數(shù)據(jù)測試
SQLite作為嵌入式數(shù)據(jù)庫的翹楚，廣受歡迎！
新生命團(tuán)隊(duì)自2010年以來，投入大量精力對SQLite進(jìn)行學(xué)習(xí)研究，成功應(yīng)用于各系統(tǒng)非致命數(shù)據(jù)場合。
SQLite極致性能
關(guān)閉同步，Synchronous=Off，提升性能。添刪改操作時不必同步等待寫入磁盤，操作系統(tǒng)會延遲若干毫秒批量寫入
設(shè)置WAL模式，Journal Mode=WAL，減少鎖定。寫入向前日志模式，避免多線程訪問時鎖定數(shù)據(jù)庫，寫入時不必使用排它鎖影響其它線程讀取，而是把事務(wù)操作寫入到WAL文件中，延遲合并
加大緩存，Cache Size=5000，提升性能。操作系統(tǒng)通過文件映射MapFile把整個數(shù)據(jù)庫文件映射進(jìn)入內(nèi)存，實(shí)際查詢時會把用到數(shù)據(jù)所在附近頁預(yù)先加載進(jìn)入緩存，極大提升查詢性能
插入速度 5000~16000tps，依賴CPU，HDD/SSD差別不大，主要受限于SQLite.Data.dll的Prepare
查詢速度 非首次查詢，緩存命中以后，索引查詢基本上都是毫秒級。數(shù)據(jù)庫較大則相應(yīng)加大緩存，速度不變。
查記錄數(shù) 單表數(shù)據(jù)超過一千萬行以后，盡量不要使用Select Count，否則可能需要十幾秒到半分鐘的樣子才能返回。NewLife.XCode封裝了'Meta.Count'
當(dāng)然，SQLite不適合多線程高并發(fā)寫入，多線程高并發(fā)讀取倒是非常不錯。
因?yàn)閿?shù)據(jù)庫就在進(jìn)程內(nèi)，高并發(fā)讀取一般比其它RDS要快一大截。
總的來說，SQLite數(shù)據(jù)庫甭管多少數(shù)據(jù)多大庫文件，只要配置得當(dāng)，內(nèi)存管夠，性能不是太大問題！
SQLite大數(shù)據(jù)
為了驗(yàn)證SQLite的性能巔峰，我們來做一個大數(shù)據(jù)測試。
模擬每天4億票銷售訂單，分表分庫，每天一個數(shù)據(jù)庫文件，有訂單號、部門節(jié)點(diǎn)、時間等。
1, Test項(xiàng)目生成4億行訂單數(shù)據(jù)，主鍵自增ID，訂單號建立索引，文件大小26.5G
2, Web項(xiàng)目，魔方+XCode，首次查詢較慢，約427毫秒，需要預(yù)熱
不同機(jī)器的首次查詢時間偏差比較大，最大可能達(dá)到幾秒鐘
本機(jī)第一次啟動該項(xiàng)目時，魔方需要從公網(wǎng)下載SQLite驅(qū)動文件以及樣式資源文件
3, 第二頁，99毫秒，操作系統(tǒng)文件映射緩存生效
4, 第20000頁，147毫秒，系統(tǒng)緩存依然生效
5, 第200000頁，32021毫秒，距離太遠(yuǎn)，文件系統(tǒng)緩存沒有命中
6, 第200001頁，867毫秒，緩存命中
