Question

我正在设置一个简单的SQLite数据库来保存传感器读数。表格看起来像这样：

sensors  
 - id (pk) 
 - name  
 - description
 - units  

sensor_readings  
 - id (pk)  
 - sensor_id (fk to sensors)  
 - value (actual sensor value stored here)
 - time (date/time the sensor sample was taken)

该应用程序将从大约30个不同的传感器每月捕获大约100,000个传感器读数，并且我希望尽可能长时间地将所有传感器读数保留在DB中。

大多数查询都采用

格式

SELECT * FROM sensor_readings WHERE sensor_id = x AND time > y AND time < z

此查询通常会返回大约100-1000个结果。

所以问题是，在上述查询变得太耗时之前，sensor_readings表有多大（在标准PC上超过几秒钟）。

我知道一个修复可能是为每个传感器创建一个单独的sensor_readings表，但如果没有必要，我想避免这样做。有没有其他方法可以优化此数据库架构？

Answer 1

如果您要在查询中使用time，则值得为其添加索引。这将是我根据您的信息建议的唯一优化。

每月100,000次插入相当于每分钟大约2.3次，因此另一个索引不会太繁重，它会加快您的查询速度。我假设所有30个传感器都有100,000次插入，而不是每个传感器100,000次，但是，即使我弄错了，每分钟70次插入仍然没问题。

如果性能确实成为问题，您可以选择将旧数据卸载到历史表（例如，sensor_readings_old），并仅在非历史表（sensor_readings）上进行查询。

然后，您至少可以获得所有数据，而不会影响正常查询。如果你真的想要获取较旧的数据，你可以这样做，但你会发现这些查询可能需要一段时间。

Answer 2

您是否正确设置了索引？除此之外，阅读http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html，唯一的答案是“你必须自己衡量” - 特别是因为这将严重依赖于硬件以及你是在使用内存数据库还是在磁盘上，如果你在事务中包装插入，则为on。

话虽这么说，我在几万行之后发现了明显的延迟，但这绝对没有优化 - 从阅读中我得到的印象是有人拥有100行数千行适当的索引等完全没有问题。

Answer 3

SQLite现在支持R树索引（http://www.sqlite.org/rtree.html），如果您打算进行大量时间范围查询，则非常理想。

汤姆

Answer 4

我知道我迟到了，但我认为这对后来看这个问题的任何人都有帮助：

只要SQLite一次只为一个应用程序/用户提供服务，SQLite在阅读时往往会相对较快。并发和阻塞可能成为多个用户或应用程序一次访问它的问题，而更强大的数据库（如MS SQL Server）往往在高并发环境中更好地工作。

正如其他人所说的那样，如果您担心读取查询的速度，我肯定会对该表进行索引。对于您的特定情况，我可能会创建一个包含id和time的索引。

您可能还需要注意写入速度。插入可以很快，但提交很慢，因此您可能希望在执行提交之前将多个插入一起批处理到一个事务中。这将在此处讨论：http://www.sqlite.org/faq.html#q19

在查询变得耗时之前，SQLite表可以保留多少行

4 个答案: