SQLite: ¿cuáles son los límites prácticos?

Question

Antes de marcar esta pregunta como duplicada, ¡POR FAVOR ME ESCUCHEN!
Ya he leído las preguntas que se hacen aquí sobre cómo mejorar el rendimiento, p. solo por mencionar algunos Improve INSERT-per-second performance of SQLite? y What are the performance characteristics of sqlite with very large database files?

Tengo dificultades para hacer que sqlite funcione con un tamaño de archivo de base de datos de 5 gigabytes. Por el contrario, hay personas que afirman que sqlite funciona 'genial' para ellos, incluso cuando el tamaño de la base de datos es tan grande como 160 GB. No lo he probado yo solo, pero a partir de las preguntas formuladas, creo que todo el benchmarking tal vez se haga con solo tabla en la base de datos.

estoy usando una base de datos con
- 20 o así mesas
- La mitad de las mesas tienen más de 15 columnas
- Cada uno de estos 15-o-tan-columna-mesas tienen 6/7 clave externa columnas - Algunas de estas tablas ya han crecido hasta tener 27 millones de registros en un mes

La máquina de desarrollo que estoy usando es una máquina Quad Core de 3 GHz con 4 gigas de RAM y aún tarda más de 3 minutos solo para consultar el row_count en estas tablas grandes.

No he podido encontrar ninguna forma de dividir los datos horizontalmente. La mejor opción que tengo es dividir los datos entre múltiples archivos de base de datos, uno para cada tabla. Pero en ese caso, hasta donde yo sé, las restricciones de la columna de la clave externa no se pueden emplear, así que tendré que crear una tabla autosuficiente (sin claves externas).

Así que mis preguntas son
a) ¿Estoy utilizando la base de datos incorrecta para el trabajo?
b) ¿Qué piensas dónde me estoy equivocando?
c) Todavía no he agregado índices a las claves foráneas, pero si solo la consulta de recuento de filas tarda cuatro minutos, ¿cómo me ayudan los índices de claves externas?

EDITAR Para proporcionar más información a pesar de que nadie ha preguntado por ella :) estoy usando la versión 3.7.9 con la versión de SQLite system.data.sqlite.dll 1.0.77.0

Edit2: PIENSO donde voy a diferenciarme de los chicos de 160 gig es que pueden seleccionar un récord individual o una pequeña gama de registros. Pero tengo que cargar todas las 27 millones de filas en mi tabla, unirlas a otras tablas, agrupar los registros como lo solicite el Usuario y devolver los resultados. Cualquier entrada sobre cuál es la mejor manera de optimizar la base de datos para tales resultados.

No puedo almacenar en caché los resultados de una consulta anterior, ya que no tiene sentido en mi caso. Las posibilidades de golpear el caché serán bastante bajas.

Answer 1

Hay mucho que considerar aquí, pero mi primer consejo sería no tomar las estadísticas de rendimiento de otros al pie de la letra. El rendimiento de la base de datos depende de muchas cosas, incluido cómo está estructurada su base de datos, la complejidad de sus consultas, qué índices ha definido (o no) y, a menudo, solo la gran cantidad de datos que contienen. Una gran cantidad de números de rendimiento reportados proviene de una gran cantidad de prueba y error, y/o la coincidencia de la base de datos para el trabajo en cuestión. Para decirlo de otra manera, el rendimiento que obtendrás de cualquier DBMS no se puede comparar con el rendimiento de otra aplicación a menos que tus conjuntos de datos y estructuras sean casi idénticos; sin duda son una guía y quizás un ideal para esforzarte. , pero no necesariamente vas a obtener un rendimiento loco "de fábrica"."

Como punto de partida, comenzaría a indexar los datos en esas tablas realmente grandes (mira, a partir de los comentarios, que tienes eso), y veré qué pasa. De acuerdo, el recuento de cuatro minutos es un tiempo bastante largo, pero no se quede ahí. Agregue algunos índices, cámbielos, pregunte si está almacenando datos que no necesita almacenar, y mire otras consultas de bases de datos, no solo la consulta de recuento, para juzgar el rendimiento. Busque otras aplicaciones y publicaciones de blog que usan SQLite para un gran número de filas, y vea qué han hecho para abordarlo (que puede incluir el cambio de bases de datos). Básicamente, intente cosas, y luego formule un juicio. No dejes que el miedo inicial te detenga, pensando que estás yendo por el camino equivocado. Tal vez lo estés, tal vez no lo estés, pero no te detengas con la consulta COUNT. Si lo rebanas, 27 millones de registros en una mesa son una mierda.

Por último, un consejo específico es este: en SQLite, no divida la base de datos en varios archivos. No veo que eso ayude, porque entonces tendrá que hacer un montón de cosas adicionales. trabajo de consulta, y luego unir manualmente sus tablas separadas después de que los resultados regresen de múltiples consultas. Esto es reinventar lo que el RDBMS hace por ti, y es una idea loca. No vas a encontrar de alguna manera una manera de hacer uniones más rápido que los creadores del sistema RDBMS; definitivamente estarías perdiendo el tiempo allí.

Answer 2

select count (*) en SQLite siempre será más lento cuando se compara con otro DMBS, ya que hace un escaneo de tabla para esa solicitud en particular. No tiene una tabla de estadísticas para ayudar. Eso no significa que las consultas de su aplicación serán lentas. Necesita probar sus consultas para realmente contar lo que puede esperar.

Algunas pautas generales: La indexación es una necesidad absoluta, porque navegar un subconjunto de datos en un árbol binario es mucho más rápido que atravesar una tabla completa cuando se trata de un tamaño enorme. Para ayudar a cargar el tiempo, debe ordenar sus datos para un índice único, y si no tiene un índice único, entonces el índice más grande. Si puede soltar los índices antes de cargarlos y volver a colocarlos, será más rápido. Si estas técnicas no pueden cumplir con sus parámetros operativos y de SLA, entonces es hora de hacer particiones horizontales, y use "adjuntar" para abarcar todo el rango de datos que necesita. SQLite puede admitir hasta 10 archivos adjuntos. Sé que algunos dicen que el trabajo de la herramienta es la partición, no los desarrolladores, pero cuando enfrenta límites físicos, tiene que arremangarse o tal vez elegir una herramienta comercial que lo haga por usted.

Answer 3

Si tienes 50 MB o más de db desplegados directamente en el lado del cliente, significa que haces algo mal. Intente migrar al servidor mientras almacena la clave: valor importante en el cliente. (solo referencias) No tendrá tiempo real, pero al menos producirá una solución adecuada. "Servidor" es una respuesta a su pregunta, es decir, si descarta u optimiza los requisitos de tiempo real, porque eso es lo que tiene (según su descripción). En cualquier caso. SQLite puede manejar casi cualquier cosa, pero a partir de la experiencia personal, simplemente trate de mantener las cosas lo más simples posible, incluso en el costo del resultado en tiempo real.