Esta es la solución más exacta que te podemos dar, pero obsérvala detenidamente y analiza si es compatible a tu trabajo.
Solución:
“Grande” es como “inteligente”, es relativo. 10 millones de filas es un buen tamaño, pero que la tabla sea grande depende de varios factores:
- Cuántos columnas y ¿cuáles son sus tipos de datos?
- cuantos indices
- cuál es el tamaño real de la tabla (por ejemplo, número de páginas * 8kb, que puede obtener de
sys.dm_db_partition_stats)? - ¿Qué tipo de consultas se ejecutan en su contra?
- ¿Los índices individuales se mantienen en la memoria o la mayoría de las consultas se benefician de un escaneo de índice agrupado (donde, esencialmente, toda la tabla debe estar en la memoria)?
- ¿Cuánta memoria hay en la máquina?
- qué hacer usted considerar grande?
Los tiempos de búsqueda no dependen necesariamente del tamaño per se, sino de la efectividad de su estrategia de indexación y los tipos de consultas que ejecuta para las búsquedas. Si tienes cosas como:
WHERE description LIKE '%foo%'
Entonces un índice normal no te va a ayudar en nada, y deberías empezar a preocuparte. Puede considerar la búsqueda de texto completo para casos como este.
10 millones de filas en una tabla con una sola columna INT (por ejemplo, una tabla de números) no es nada. 10 millones de filas de productos con descripciones largas, XML, datos geográficos, imágenes, etc. es otra muy distinta.
Hay una razón por la que las especificaciones de capacidad máxima para SQL Server no documentan un límite superior para el número de filas en una tabla.
grande no es un concepto útil en el diseño de db.
El rendimiento está determinado por muchas cosas, pero la etiqueta large no es uno de ellos. En su lugar, preocúpate por:
- hardware
- Configuración de sistema operativo y base de datos
- diseño de esquema
- indexación
- optimización de consultas
- lo más importante, probar usted mismo en hardware equivalente con un volumen de datos equivalente y bajo uso simultáneo
Solo así tendrás una respuesta que sea relevante para ti. Más allá de esto, el diseño de la aplicación también es un factor muy importante. Las consultas N+1 y el almacenamiento en caché pueden tener efectos enormes en el rendimiento percibido (y real).
Como dijo Aaron, es relativo. Pero tal vez pueda elaborar algunos.
En primer lugar, un factor importante es el tamaño de las columnas. Si tiene una tabla de nada más que 10 millones de enteros (y hay razones por las que podría querer algo así, mire Tally Tables), entonces no es grande en absoluto. Por otro lado, una tabla desnormalizada de solo cien filas puede ocupar mucho espacio y tener problemas de rendimiento masivos si cada fila contiene, por ejemplo, un campo de identificación con un número entero que actúa como principal. key seguido de un varchar (max) con html y luego una secuencia de columnas varbinary (max) que contenían jpg utilizados por ese html.
Entonces, para controlar el tamaño de la tabla, debe observar tanto la cantidad de filas como el tamaño de cada fila. Una métrica para el tamaño que podría ser un poco más útil es observar el espacio que ocupa. (Suponiendo que sea posterior a SQL Server 2000, puede hacer clic con el botón derecho en la tabla en SSMS, ir a las propiedades y luego a la página Almacenamiento).
Por supuesto, todavía es difícil decir cuándo eso comenzará a afectar el rendimiento. Sin duda, notará un cambio en el rendimiento una vez que la tabla se vuelva demasiado grande para caber dentro de la RAM, pero eso puede suceder con frecuencia con conjuntos de datos de tamaño decente, especialmente si elige desnormalizar parcialmente y no es motivo de preocupación. Tener índices que son demasiado grandes para caber dentro de la RAM puede causar un mayor problema de rendimiento, y ese puede ser motivo de evaluación. Pero no es necesariamente un problema, especialmente si está destinado a ser un índice de cobertura para alguna consulta y está trabajando con un entorno con restricciones de RAM (lo que significa con restricciones de RAM también es relativo, pero como regla general, trataría de poner al menos 8 GB incluso en un escritorio que iba a hacer un trabajo serio con SQL Server).
Ahora, el tamaño de la tabla sin duda puede ser un factor en la velocidad de búsqueda y hay formas de lidiar con eso. Pero antes de hablar de eso, permítanme señalar que normalmente es uno de los factores más pequeños que consideraría en términos de rendimiento. Escribí un artículo sobre esto recientemente aquí. Antes de pensar en el tamaño de la tabla, me aseguraría de que las consultas estuvieran optimizadas y los índices tuvieran sentido. Incluso consideraría aumentar la RAM y obtener discos duros más rápidos (los SSD marcan la diferencia si puede permitirse uno lo suficientemente grande para sus propósitos) antes de preocuparme por el tamaño de las mesas.
Pero, si desea disminuir el tamaño de la tabla:
- Normalizar. En realidad, esto puede tener algunos grandes inconvenientes para el rendimiento, pero puede tener algunas ventajas de rendimiento y tiene ventajas de consistencia de big data, así como ventajas de almacenamiento.
- Considere sus tipos de datos. Si necesita NVarchar, necesita NVarchar. Pero si varchar funciona, usará menos espacio. Lo mismo con int vs bigint.
- Dividir. Nuevamente, si se hace mal, esto puede degradar el rendimiento en lugar de mejorarlo, pero si se hace bien, puede ayudar con el rendimiento. Puede ser algo complicado hacerlo bien, así que acérquese con precaución.
- Mueva datos antiguos e innecesarios a un almacén de archivo y fuera del sistema principal. Por supuesto, esto depende de obtener la definición correcta de datos innecesarios.
Resumen:
Esto se hizo más largo de lo que esperaba, así que para resumir:
- Lo que es grande es relativo, pero debe considerar el tamaño de la columna junto con la cantidad de filas.
- El tamaño de la tabla definitivamente puede afectar el rendimiento, pero muchas otras cosas lo afectan más, por lo que no miraría allí primero ni en segundo lugar.
- Si debe reducir el tamaño de la tabla, básicamente deshágase de los datos que no necesita y reasigne otros datos a otros lugares. Pero tienes que ser inteligente acerca de cómo o puedes hacer más daño que bien.