¿Cuántas filas puede contener una tabla SQLite antes de que las consultas se conviertan en tiempo?

Question

Estoy configurando una base de datos SQLite simple para almacenar las lecturas del sensor. Las mesas se verá algo como esto:

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) 

La solicitud será la captura de alrededor de 100.000 lecturas de los sensores al mes de unos 30 sensores diferentes, y me gustaría seguir todas las lecturas de los sensores en el PP el mayor tiempo posible.

mayoría de las consultas serán en forma

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

Esta consulta devolverá normalmente unos 100-1000 resultados.

Así que la pregunta es, ¿qué tan grande puede llegar la tabla sensor_readings antes de que la consulta anterior sea demasiado lenta (más de un par de segundos en una PC estándar).

Sé que una solución podría ser crear una tabla sensor_readings separada para cada sensor, pero me gustaría evitar esto si no es necesario. ¿Hay alguna otra forma de optimizar este esquema de base de datos?

Answer 1

¿Está configurando los índices correctamente? Además de eso, y al leer http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html, la única respuesta es "tendrá que medirse a sí mismo", especialmente porque esto dependerá en gran medida del hardware y de si está utilizando una base de datos en memoria o en disco, y si envolver insertos en transacciones o no.

Dicho esto, he notado retrasos notables después de un par de decenas de miles de filas, pero eso no estaba optimizado en absoluto: de leer un poco tengo la impresión de que hay personas con cientos de miles de filas con índices adecuados, etc. que no tienen ningún problema.

Answer 2

Si va a utilizar time en las consultas, vale la pena agregarle un índice. Esa sería la única optimización que sugeriría según su información.

100.000 inserciones por mes equivale a aproximadamente 2,3 por minuto, por lo que otro índice no será demasiado oneroso y acelerará sus consultas. Supongo que hay 100.000 inserciones en los 30 sensores, no 100.000 para cada sensor, pero, incluso si estoy equivocado, 70 inserciones por minuto todavía deberían estar bien.

Si el rendimiento se convierte en un problema, usted tiene la opción para descargar los datos más antiguos en una tabla histórica (por ejemplo, sensor_readings_old) y sólo hacer sus consultas sobre la mesa no histórico (sensor_readings).

Entonces al menos tiene todos los datos disponibles sin afectar las consultas normales. Si realmente desea obtener los datos anteriores, puede hacerlo, pero sabrá que las consultas pueden tardar un poco más.

Answer 3

SQLite ahora es compatible con los índices de árbol R (http://www.sqlite.org/rtree.html), ideal si tiene la intención de hacer muchas consultas de rango de tiempo.

Tom

Answer 4

Sé que vengo a esta tarde, pero pensé que esto podría ser útil para cualquier persona que viene mirando a esta cuestión más adelante:

SQLite tiende a ser relativamente rápido en la lectura, siempre y cuando solo está sirviendo a una sola aplicación/usuario a la vez. La simultaneidad y el bloqueo pueden convertirse en problemas con múltiples usuarios o aplicaciones que acceden a él en una sola vez y las bases de datos más robustas, como MS SQL Server, tienden a funcionar mejor en un entorno de alta concurrencia.

Como han dicho otros, definitivamente indexaría la tabla si le preocupa la velocidad de las consultas de lectura. Para su caso particular, probablemente crearía un índice que incluye tanto el id como el tiempo.

Es posible que también desee prestar atención a la velocidad de escritura. La inserción puede ser rápida, pero las confirmaciones son lentas, por lo que es probable que desee agrupar muchas inserciones en una transacción antes de presionar confirmar. Esto se discute aquí: http://www.sqlite.org/faq.html#q19