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

时间:2009-08-20 13:38:53

标签: sql database-design sqlite

我们有一个非常简单的数据库:

 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是主键,所以现在我们的需求可以满足性能要求。我想我应该使用一个单独的连接进行搜索,对吗?

  4. 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)。

2 个答案:

答案 0 :(得分:2)

由于数据是暂时的 - 而且很小 - 为什么要使用数据库?

对于简单的平面文件目录,你会更开心。

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

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

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

  • 写入并刷新,以便在每个I / O之后文件正确并完整。如果您的读者优雅地处理不完整的最后记录,您甚至不需要锁定。

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

答案 1 :(得分:0)

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