建議數據庫設計 - 密集的插入和刪除大量的記錄

Question

我們有一個數據庫，一個非常簡單的模式：

CREATE TABLE IF NOT EXISTS tblIndex(
    frame_type INT, 
    pts VARCHAR(5), 
    ts_start INT primary key, 
    ts_end INT) 

和應用場景是：

1. 每第二個用戶將插入2〜50條記錄，這些記錄的ts_start字段不斷增加。 8小時後，最多有1_800_000條記錄。通過將同步模式設置爲關，迄今爲止性能似乎不錯。因爲每條記錄的數據只有16個字節，所以即使插入速度不太快，我們也可以使用一些緩衝區。

2. 8小時後，用戶會告訴我告訴上限ts_start刪除最早的數據，所以我會做

   DELETE FROM tblIndex WHERE ts_start < upper_bound_ts_start.

   刪除90_000（這是半小時的記錄） 1_800_000現在需要17秒。垃圾位比預期的要長。任何方式來減少這種情況？我們不在乎記錄是否立即同步到硬盤。我們正在考慮啓動一個單獨的線程來執行刪除操作，以使此調用成爲異步。我不確定的是（長時間）刪除是否會影響插入性能，如果他們共享相同的連接？或者我應該使用分離的連接進行插入和刪除？但是通過這種方式，他們是否需要在應用程序級別同步？

3. 搜索。 SELECT ts_start FROM tblIndex WHERE ts_start BETWEEN ? AND ? - 由於ts_start是主鍵，因此現在我們的需求可以確保性能。我想我應該使用分離的連接進行搜索，對吧？

配置的SQLite：

hard disk database (usb interface) 
cache size is 2000 
page size is 1024 
sync mode is 0 (off) 
journal_mode mode is truncate 

感謝您的任何建議，以提高刪除性能或對整體設計。

編輯：350M MIPS CPU，沒有太多內存（< 2M）特定於此應用程序。

Answer 1

由於數據是短暫的 - 很小 - 爲什麼你要使用數據庫？

你會對一個簡單的平面文件目錄感到高興。

您的網頁查詢可以簡單地讀取相關的一組文件並返回所需的結果。 1_800_000個16字節的記錄僅僅是28Mb的文件數據。你可以將整件事物讀入記憶中，在記憶中進行處理，並呈現結果。

一個單獨的進程可以刪除在午夜一天一次的舊文件。

第三個進程可以每秒向工作文件追加2-50個16字節的記錄。

• 寫入和刷新以便文件在每個I/O之後是正確和完整的。如果您的讀者正常處理不完整的最後一條記錄，則甚至不需要鎖定。

• 用基於時間的序列號命名每個文件。例如，您可以將系統時間（以秒爲單位）除以4 * 60 * 60並截斷答案。這是一個序列號，每4小時進行一次，創建一個新文件。 8小時數據的是這些文件的3（2之前的4小時的文件，再加上當前的工作文件。）

Answer 2

怎麼樣有一個SQLite數據庫每半小時？換句話說，每半小時啓動一個新的數據庫文件，並刪除舊的數據庫文件。