数据库设计建议——密集插入和删除大量记录

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.

   现在从 1_800_000 中删除 90_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，没有太多内存 (

Answer 1

既然数据是短暂的——而且很小——你为什么要使用数据库？

你会更喜欢一个简单的平面文件目录。

您的网络查询可以简单地读取相关的文件集并返回所需的结果。 16 字节的 1_800_000 条记录只是 28Mb 的文件数据。您可以将整个内容读入内存，在内存中进行处理并呈现结果。

一个单独的进程可以在每天午夜删除一次旧文件。

第三个进程每秒可以将 2-50 条 16 字节的记录附加到工作文件中。

• 写入并刷新，以使文件在每次 I/O 后正确且完整。如果您的阅读器优雅地处理不完整的最后一条记录，您甚至不需要锁。

• 使用基于时间的序列号为每个文件命名。例如，您可以将系统时间（以秒为单位）除以 4*60*60 并截断答案。这是一个序列号，每 4 小时前进一次，创建一个新文件。 8 小时的数据是其中的 3 个文件（2 个之前的 4 小时文件，加上当前的工作文件。）

Answer 2

每半小时有一个sqlite数据库怎么样？换句话说，每半小时启动一个新的数据库文件，然后删除旧的。