SQL Server: el número máximo de filas en la tabla [cerrado]

Desarrollo software que almacena muchos datos en una de sus tablas de base de datos (SQL Server versión 8, 9 o 10). Digamos que alrededor de 100,000 registros se insertan en esa tabla por día. Esto es aproximadamente 36 millones de registros por año. Por temor a perder rendimiento, decidí crear una nueva tabla todos los días (una tabla con la fecha actual en su nombre) para reducir el número de registros por tabla.

¿Podría decirme si fue una buena idea? ¿Existe un límite de registros para las tablas del servidor SQL? ¿O sabe cuántos registros (más o menos) se pueden almacenar en una tabla antes de que el rendimiento se reduzca significativamente?

Es difícil dar una respuesta genérica a esto. Realmente depende de varios factores:

• de que tamaño es tu fila
• qué tipo de datos almacena (cadenas, blobs, números)
• ¿Qué hace con sus datos? (simplemente guárdelos como archivo, consúltelos regularmente)
• ¿Tiene índices en su mesa? ¿Cuántos
• cuáles son las especificaciones de su servidor

etc.

Como se respondió en otra parte aquí, 100,000 por día y, por lo tanto, por mesa es excesivo; sugeriría mensual o semanalmente, tal vez incluso trimestralmente. Cuantas más tablas tenga, mayor será la pesadilla de mantenimiento / consulta.

Estas son algunas de las especificaciones de capacidad máxima para SQL Server 2008 R2

• Tamaño de la base de datos: 524,272 terabytes
• Bases de datos por instancia de SQL Server: 32,767
• Grupos de archivos por base de datos: 32,767
• Archivos por base de datos: 32,767
• Tamaño de archivo (datos): 16 terabytes
• Tamaño de archivo (registro): 2 terabytes
• Filas por tabla: limitado por el almacenamiento disponible
• Tablas por base de datos: limitado por la cantidad de objetos en una base de datos

Tengo una tabla de tres columnas con poco más de 6 mil millones de filas en SQL Server 2008 R2.

Lo consultamos todos los días para crear gráficos de análisis del sistema minuto a minuto para nuestros clientes. No he notado ningún impacto en el rendimiento de la base de datos (aunque el hecho de que crece ~ 1 GB cada día hace que la gestión de las copias de seguridad sea un poco más complicada de lo que me gustaría).

Actualización de julio de 2016

Llegamos a ~ 24.5 mil millones de filas antes de que las copias de seguridad fueran lo suficientemente grandes como para decidir truncar los registros de más de dos años (~ 700 GB almacenados en varias copias de seguridad, incluso en cintas caras). Vale la pena señalar que el desempeño no fue un motivador significativo en esta decisión (es decir, todavía estaba funcionando muy bien).

Para cualquiera que se encuentre tratando de eliminar 20 mil millones de filas de SQL Server, le recomiendo este artículo . Código relevante en caso de que el enlace muera (lea el artículo para obtener una explicación completa):

ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO

BEGIN TRY
    BEGIN TRANSACTION
        -- Bulk logged 
        SELECT  *
        INTO    dbo.bigtable_intermediate
        FROM    dbo.bigtable
        WHERE   Id % 2 = 0;

        -- minimal logged because DDL-Operation 
        TRUNCATE TABLE dbo.bigtable;  

        -- Bulk logged because target table is exclusivly locked! 
        SET IDENTITY_INSERT dbo.bigTable ON;
        INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
        SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
        SET IDENTITY_INSERT dbo.bigtable OFF;
    COMMIT
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK
END CATCH

ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO

Actualización de noviembre de 2016

Si planea almacenar esta cantidad de datos en una sola tabla: no lo haga. Le recomiendo que considere la partición de tablas (ya sea manualmente o con las funciones integradas si está ejecutando la edición Enterprise). Esto hace que eliminar datos antiguos sea tan fácil como truncar una tabla una vez a la (semana / mes / etc.). Si no tiene Enterprise (que no tenemos), simplemente puede escribir un script que se ejecute una vez al mes, descarte tablas de más de 2 años, cree la tabla del próximo mes y regenere una vista dinámica que se una a todas las particiones tablas juntas para facilitar la consulta. Obviamente, usted debe definir "una vez al mes" y "más de 2 años" en función de lo que tenga sentido para su caso de uso.

No conozco un límite de filas, pero conozco tablas con más de 170 millones de filas. Puede acelerarlo utilizando tablas particionadas (2005+) o vistas que conectan varias tablas.

No conozco MSSQL específicamente, pero 36 millones de filas no son grandes para una base de datos empresarial; al trabajar con bases de datos de mainframe, 100,000 filas me suena como una tabla de configuración :-).

Si bien no soy un gran admirador de algunos de los software de Microsoft, no estamos hablando de Access aquí: supongo que pueden manejar tamaños de base de datos bastante sustanciales con su DBMS empresarial.

Sospecho que los días pueden haber sido una resolución demasiado buena para dividirlo, si es que es necesario dividirlo.

Tenemos tablas en SQL Server 2005 y 2008 con más de mil millones de filas (30 millones agregadas diariamente). No me puedo imaginar ir al nido de ratas dividiendo eso en una nueva mesa cada día.

Es mucho más económico agregar el espacio en disco apropiado (que necesita de todos modos) y RAM.

Depende, pero yo diría que es mejor tener todo en una mesa por simplicidad.

100.000 filas al día no es realmente una cantidad enorme. (Dependiendo del hardware de su servidor). Personalmente, he visto que MSSQL maneja hasta 100 millones de filas en una sola tabla sin ningún problema. Siempre que mantenga sus índices en orden, todo debería estar bien. La clave es tener un montón de memoria, de modo que los índices no tienen que ser cambiados en el disco.

Por otro lado, depende de cómo esté utilizando los datos, si necesita hacer muchas consultas, y se necesitarán sus datos poco probables que abarcan varios días (por lo que no necesitará unirse a las tablas) será más rápido para separarlo en varias tablas. Esto se usa a menudo en aplicaciones como el control de procesos industriales, donde podría leer el valor en, digamos, 50,000 instrumentos cada 10 segundos. En este caso, la velocidad es extremadamente importante, pero la simplicidad no lo es.

Desbordamos una clave primaria entera una vez (que es ~ 2.4 mil millones de filas) en una tabla. Si hay un límite de filas, es probable que nunca lo alcance con solo 36 millones de filas por año.

Puede completar la tabla hasta que tenga suficiente espacio en disco. Para un mejor rendimiento, puede intentar la migración a SQL Server 2005 y luego particionar la tabla y colocar partes en diferentes discos (si tiene una configuración RAID que realmente podría ayudarlo). La partición solo es posible en la versión empresarial de SQL Server 2005. Puede ver un ejemplo de partición en este enlace: http://technet.microsoft.com/en-us/magazine/cc162478.aspx

También puede intentar crear vistas para la parte de datos más utilizada, que también es una de las soluciones.

Espero que esto haya ayudado ...

La tabla más grande que he encontrado en SQL Server 8 en Windows2003 fue de 799 millones con 5 columnas. Pero si es buena voluntad o no se medirá contra el SLA y el caso de uso, por ejemplo, cargue 50-100,000,000 registros y vea si todavía funciona.

SELECT Top 1 sysobjects.[name], max(sysindexes.[rows]) AS TableRows, 
  CAST( 
    CASE max(sysindexes.[rows]) 
      WHEN 0 THEN -0 
      ELSE LOG10(max(sysindexes.[rows])) 
    END 
    AS NUMERIC(5,2)) 
  AS L10_TableRows 
FROM sysindexes INNER JOIN sysobjects ON sysindexes.[id] = sysobjects.[id] 
WHERE sysobjects.xtype = 'U' 
GROUP BY sysobjects.[name] 
ORDER BY max(rows) DESC

Particione la tabla mensualmente. Esa es la mejor manera de manejar tablas con gran afluencia diaria, ya sea Oracle o MSSQL.