Capacidad máxima de tabla en SQL Server 2008


11

Tengo una aplicación que inserta más de mil millones de filas anualmente en una tabla. Esta tabla contiene cierta varchary bigintcolumnas y una columna BLOB también.

Los mil millones de filas consisten en datos históricos que se guardan para fines de seguimiento. Entonces, me preguntaba si habrá una limitación de capacidad de la tabla si continúo en esta estructura de acuerdo con este artículo de MSDN sobre el tamaño máximo de la tabla .

¿El tamaño del archivo de datos mencionado en ese enlace se refiere al grupo de archivos de datos de la tabla?


@marc_s gracias por atrapar eso. siéntase libre de unirse a nosotros en The Heap donde, entre otras cosas, atraemos atención colectiva a estos
JNK

¿Cuál es el tamaño máximo de cada fila?
Nick Chammas

Respuestas:


6

No hay límite práctico excepto el espacio en disco. Leí la tabla a la que vinculaste por completo y la revisé.

Si necesita superar los 16 TB, necesita varios archivos (un procedimiento simple).


Supongo que esto se puede lograr al particionar la tabla y al dividir la partición para usar diferentes grupos de archivos, si estoy en lo correcto
GAP

1
Eso ni siquiera es necesario. Simplemente agregue un nuevo archivo (al grupo de archivos existente). SQL Server comenzará a llenar todos los archivos de manera uniforme. Si un archivo ya no puede crecer, solo crecerá el otro archivo.
usr

2

una tabla en sql server 2008 puede manejar una gran cantidad de registros y, como mencionó @usr, depende del espacio en disco, pero se recomienda que si su tabla tiene muchas filas y sigue creciendo, use la Tabla Particionada http://technet.microsoft. com / es-us / library / dd578580 (v = sql.100) .aspx

Cuando una tabla de base de datos crece a cientos de gigabytes o más, puede ser más difícil cargar nuevos datos, eliminar datos antiguos y mantener índices

más información al respecto

http://msdn.microsoft.com/en-us/library/ms190787.aspx

y cómo implementarlo http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitions-tutorial-how-to-horizontal-partition-database-table/


Sin embargo, debes tener mucho cuidado con la partición. La función y la clave deben considerarse cuidadosamente, así como el caso de uso. El campo lógico para particionar nunca puede usarse en ninguna de las consultas, lo que mataría el rendimiento.
JNK

Es cierto, pero miles de millones de filas en una sola tabla también afectarán el rendimiento, también existe la opción de dividir sus datos en muchas tablas, por ejemplo, una tabla separada para cada año y si desea ver todos los datos puede usar una vista A pero en menos la inserción y la actualización serán más rápidas en cada tabla
AmmarR

Las inserciones en una tabla enorme no son necesariamente lentas, sino que dependen de claves e índices. Hago cargas mensuales de alrededor de 30 millones de filas en una tabla que tiene 700 millones de filas existentes, y no hacemos particiones. Intenté particionar pero causó más problemas de los que resolvió. Esta es realmente una pregunta si quieres echarle un vistazo.
JNK

Estaba pensando en mover mis datos del historial a una tabla separada y crear una vista de unión para que la aplicación pueda usarla cuando necesite el historial de consultas + los últimos datos, que representan menos del 25% de las consultas que tengo en el sistema. ¿Será esto más eficiente que tener múltiples archivos de datos o dividir la tabla en función de la columna que marca los datos como los más recientes? ¿De las operaciones IO que serán más eficientes? porque mi duda es que será igual desde la perspectiva de IO en ambas soluciones.
GAP

cualquier enfoque que adopte tiene sus mejores prácticas que pueden hacer que sea bueno o malo, es decir, si tiene muchas tablas, su consulta será complicada y será difícil de mantener, si tiene una tabla y utiliza el particionamiento de tablas, existen consideraciones diferentes como su edición sql debe ser empresarial, etc., se recomienda tener muchos archivos de datos para mejores operaciones de E / S, pero también tiene sus mejores prácticas, para el rendimiento sql no hay una forma directa ...
AmmarR

0

Quizás una vista particionada funcionaría.

Del artículo de MSDN Vista con particiones que usa :

Las vistas particionadas permiten que los datos de una tabla grande se dividan en tablas miembro más pequeñas. Los datos se dividen entre las tablas de miembros en función de rangos de valores de datos en una de las columnas. Los rangos de datos para cada tabla de miembros se definen en una restricción CHECK especificada en la columna de partición. Luego se define una vista que usa UNION ALL para combinar selecciones de todas las tablas de miembros en un único conjunto de resultados. Cuando las instrucciones SELECT que hacen referencia a la vista especifican una condición de búsqueda en la columna de partición, el optimizador de consultas usa las definiciones de restricción CHECK para determinar qué tabla miembro contiene las filas.

No estoy seguro de cómo difiere de una tabla dividida sobre la que AmmarR proporcionó información en su respuesta.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.