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


80

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?


33
"Los programadores pierden una enorme cantidad de tiempo pensando o preocupándose por la velocidad de las partes no críticas de sus programas, y estos intentos de eficiencia en realidad tienen un fuerte impacto negativo cuando se consideran la depuración y el mantenimiento. Debemos olvidarnos de las pequeñas eficiencias, por ejemplo, El 97% de las veces: la optimización prematura es la raíz de todos los males. Sin embargo, no debemos dejar pasar nuestras oportunidades en ese crítico 3% ". Knuth 1974
Matthew Lock

Respuestas:


36

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.


13
Me gustaría reforzar una "pesadilla de consultas / mantenimiento más grande"; por experiencia personal, evitaría dividirme en tablas como la plaga.
Daniel James Bryars

92

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

22
Sospecho que si tiene más de 9,223,372,036,854,775,807 filas, sin embargo, tendría problemas (tamaño máximo de a bigint)
Martin Smith

11
¿Alguna vez ha calculado la cantidad de años que le tomaría llegar a ese recuento de filas en las 100000 filas / día que mencionó el OP?
Erwin Smout

75
Publicando esto para los vagos: 252,695,124 años.
NotMe

18
@NotMe No es para revivir y ser quisquilloso, pero tengo 252695124297 años. (A veces desearía ser de la población perezosa a la que se refirió)
philthyfool

4
@philthyfool Un día en un año bisiesto es una gran diferencia. Recibo 252,522,163,911. Además, estos fueron minutos perfectamente buenos de mi vida que no puedo recuperar ahora.
Suamere

53

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

Número de filas

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.


14
Hasta 10.5 mil millones, aún resoplando. Simplemente no intente ejecutar COUNT (). ;)
Dan Bechard

6
Ha pasado un año, estamos en 16.5 mil millones de filas. Acabamos de agregar una fuente de datos adicional, por lo que ahora está creciendo un poco más rápido. También hemos movido esta base de datos a su propia instancia de SQL para permitirnos dedicar memoria sin privar a las otras bases de datos del servidor. Todavía puedo trazar cualquier punto de datos durante cualquier período de 24 horas en los últimos 3 años en menos de un segundo. A nuestros analistas les encanta.
Dan Bechard

Sé que ha pasado un tiempo, pero ¿puede decirme en qué tipo de hardware estaba ejecutando esta base de datos? Muy curioso, ya que tenemos una tabla de 5 mil millones de filas, que crece 1 mil millones al año, y me gustaría saber si esto comienza a ser problemático en el futuro
Jeroen1984

3
@ Jeroen1984 Es una máquina virtual que se ejecuta en un host Hyper-V ProLiant DL360e Gen8 con dos procesadores Intel (R) Xeon (R) CPU E5-2430. La máquina virtual tiene 38 GB de RAM asignada estáticamente y una cierta cantidad de procesadores virtuales que no recuerdo.
Dan Bechard

19

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.


19

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.


5

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.


4

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.


3

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.


2

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 ...


0

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.


2
No estoy seguro de que esto sea realmente una respuesta.
Andrew Barber

-1
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

Ejecuté esta consulta y obtuve este resultado. Tengo la tabla UrlCategories en mi base de datos. Entonces, ¿qué significa este resultado? Nombre TableRows L10_TableRows UrlCategories 7 0.85
Aditya Bokade

-4

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


4
No estoy seguro de cómo esta es una respuesta a la pregunta específica formulada.
Andrew Barber
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.