6

我正在建立一个简单的 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 个传感器读数，我希望尽可能长时间地将所有传感器读数保留在数据库中。

大多数查询将采用以下形式

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

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

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

我知道一个解决方法可能是为每个传感器创建一个单独的 sensor_readings 表，但如果没有必要，我想避免这种情况。还有其他方法可以优化此数据库模式吗？

4

4 回答 4

4

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

每月 100,000 次插入相当于每分钟大约 2.3 次，因此另一个索引不会太繁重，并且会加快您的查询速度。我假设在所有 30 个传感器中插入 100,000 次，而不是每个传感器 100,000 次，但是，即使我弄错了，每分钟 70 次插入应该还是可以的。

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

然后，您至少可以在不影响正常查询的情况下获得所有可用数据。如果您真的想获取较旧的数据，您可以这样做，但您会意识到查询可能需要更长的时间。

于 2008-10-09T08:03:01.000 回答
2

您是否正确设置索引？除此之外，阅读http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html，唯一的答案是“你必须自己衡量”——尤其是因为这在很大程度上取决于硬件以及是否您正在使用内存数据库或磁盘，以及是否将插入包装在事务中。

话虽这么说，在几万行之后我已经遇到了明显的延迟，但这绝对不是优化的——从阅读中我得到的印象是，有些人有数百行有适当的索引等. 完全没有问题的人。

于 2008-10-09T06:40:30.340 回答
1

SQLite 现在支持 R-tree 索引 ( http://www.sqlite.org/rtree.html )，如果您打算进行大量时间范围查询，这是理想的选择。

汤姆

于 2008-10-13T10:24:29.907 回答
1

我知道我来晚了，但我认为这可能对稍后查看此问题的任何人有所帮助：

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

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

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

于 2012-02-06T23:39:31.603 回答