2009-03-18 11 views
10

¿Existe alguna regla rígida sobre qué tan grande es demasiado grande para una tabla SQL?¿Cuántas filas de datos hay demasiadas filas de datos?

Estamos almacenando datos de seguimiento de SCORM en un formato de nombre/valor de par y podría haber entre 4 y 12 filas por usuario por curso, en el futuro esto será algo malo ya que hay cientos de cursos y miles de usuarios?

Respuesta

8

Personalmente he tenido tablas en producción con 50 millones de filas, y esto es pequeño comparado con lo que he escuchado. Es posible que necesite optimizar su estructura con la partición, pero hasta que pruebe su sistema en su entorno, no debe perder el tiempo haciendo eso. Lo que describiste es bastante pequeño IMHO

Debo agregar que estaba usando SQL Server 2000 & 2005, cada DBMS tiene sus propias limitaciones de tamaño.

+1

Veo que publicó su respuesta en 2009, ¿podría decirnos cuántas filas tiene ahora? Solo estoy interesado en saber y si no te importa configuraciones de hardware. Siempre me confundo con esto porque Wikipedia tiene 28,103,538 artículos, pero para estos están usando alrededor de 400 servidores. Me pregunto por qué esas muchas y esas son páginas estáticas ... Gracias por su respuesta. – Bujji

+2

@Bujji He trabajado en un DB de tamaño de terabyte en SQL 2008 ... en cuanto a por qué WikiPedia necesita 400 servidores ... Apuesto a que pueden servir un artículo muy rápido desde un servidor, pero no sirven una página para un usuario a la vez, probally tienen miles de usuarios accediendo a las páginas. – JoshBerke

+0

Gracias Josh Por responder a mi comentario. Esto me ayuda y usted es tan útil – Bujji

2

No realmente. Todo depende de las necesidades de su negocio, y tendrá que comprar el producto que respalda su recuento de filas estimado.

11

El número mágico es miles de millones. Hasta que no llegue a miles de millones de filas de datos, no está hablando de mucha información.

Haz las cuentas.

4-12 filas por usuario por curso, ... cientos de cursos y miles de usuarios?

400,000 a 1,200,000 filas. Supongamos 1000 bytes por fila.

Eso es de 400Mb a 1.2Gb de datos. Puede comprar unidades de 100 Gb por $ 299 en la tienda Apple. Puede pasar fácilmente más de $ 299 de tiempo facturable sudando por detalles que ya no importan demasiado.

Hasta que llegue a 1Tb de datos (1,000 Gb), no está hablando de mucha información.

+0

O un 80GB de Newegg por $ 33.99 – Tmdean

+0

Unidad de 100 gb por $ 299?¡Quizás hace 5 años! ¡Hoy puedes obtener 1 TB + por $ 100! – rmeador

+10

Sí, pero dijo "en la tienda de Apple". Apenas puedes conseguir un mouse por menos de $ 100 allí. –

6

100 (cursos) * 1000 (usuarios) * 10 (registros) es solo un millón. Ese es el extremo inferior, pero una base de datos decente debería manejarlo bien.

Lo que parece dudoso son los pares Nombre/Valor. Eso limitará su capacidad para indexar correctamente las cosas, lo que será crítico para un buen rendimiento.

2

No, en realidad no existe una regla estricta sobre cuántas filas puede tener en una tabla, depende mucho de la cantidad de datos que haya en las filas, y qué tan bien se pueden indexar los datos.

Una estimación rápida de las cifras que usted indica da como decenas de millones de filas. Eso ciertamente no es demasiado, pero es suficiente que podría ser un problema si no eres un poco cuidadoso.

¿Quizás la tabla podría estar normalizada? ¿Se producen los mismos nombres mucho, por lo que podría poner los nombres en una tabla separada y usar la identificación en la tabla?

1

No creo que realmente haya un límite aquí, pero espacio en el disco. PERO POR FAVOR agrega buenos índices mientras que es pequeño, porque cuando la tabla es enorme, los índices tardarán mucho más en agregarse. Además, si tienes índices erróneos, las consultas se ralentizarán a medida que crezca y la gente se quejará cuando realmente no haya nada malo, sino un índice de mierda o sin índice.

3

Una vez trabajé en un sistema de formularios web con más de 300 millones de filas en su tabla de pares de nombre/valor. Muchos de los formularios tenían más de 300 filas por envío de formulario. El rendimiento no fue tan malo en realidad, ¡pero fue un PITA total para consultar! Mi capacidad de escritura sql definitivamente mejoró durante la vida de este concierto.

Pero en mi humilde opinión, si tiene algo que decir deshacerse de él a favor de una tabla normalizada estándar.

0

He trabajado en las bases de datos en la que trató de crear tablas con 2B filas de datos - que no funciona, llegamos a 500M y re-diseñado. Uno de los mayores inconvenientes de trabajar con una tabla tan grande fue el tiempo necesario para realizar eliminaciones: a menudo veo el enfoque donde los archivos antiguos se archivan y luego se eliminan de la tabla principal. Si la tabla es lo suficientemente grande, la eliminación se ejecutará durante muchas horas a medida que se reconstruyan los índices.

No está seguro de que el punto de corte no es más que el instinto indica una mesa> 10M filas es probablemente demasiado grande. Nuestro enfoque fue dividir los datos por fecha, por lo que terminamos con una tabla para una semana de datos y otra tabla de resumen para meses y otro resumen para años, muy común en DataWarehousing. Por cierto, esto fue en SQL 7.0, interesado en saber si los DB son mejores en este tipo de cosas todavía?

+0

En Oracle usa particionamiento. Los datos con diferentes fechas van a diferentes particiones. Las particiones antiguas pueden archivarse en cintas y soltarse con algo como "ALTER TABLE DROP PARTITION" en segundos. – jva

4

hay regla dura y rápida, pero hay una manera fuerte y rápido para obtener un número.

Escriba un programa para completar su tabla con datos ficticios aproximándose aproximadamente a la forma esperada de los datos reales (ej. Similar regularidad, caracteres, patrones, etc.) Ejecute pruebas de rendimiento contra ella usando consultas reales con los datos ficticios, aumentando gradualmente el número de filas en la tabla, tal vez por pasos de 1000 o 10000 filas.

En la cúspide de cuando el rendimiento de las consultas (por ejemplo, consultas completas por segundo) se convierte en inaceptable, tendrá su número de "demasiado grande" de filas.

+0

Puede ser creativo generando los datos ficticios. Si una columna de la tabla está compuesta por texto en inglés, instálelo con palabras aleatorias de un diccionario. Si contiene nombres, descargue una lista de nombres, cámbielos para producir nombres completos falsos, luego inunde la tabla con ellos en la frecuencia esperada. – Triynko

+0

+1 Buena sugerencia práctica allí. –

0

Su pregunta genera más preguntas que respuestas.

  • ¿qué motor de base de datos estás utilizando? Es difícil darle una buena respuesta sin esto.
  • ¿cuál es la estructura de la tabla? Dependiendo de su tipo de datos, la distribución de la tabla en el disco dependerá de esto.
  • ¿por qué no almacenar un registro por usuario/curso? Como está almacenando datos SCORM, supongo que esto significa que está almacenando datos SCORM estándar como la finalización, el éxito, los intentos, el tiempo total, etc. No es necesario crear múltiples filas para esto.

He creado algunas bases de datos que almacenan datos SCORM, y nunca he tenido que utilizar un sistema de etiquetas/valores como el que sugiere.

Una cosa que quiero recordar es que no es el # de filas en la tabla, es el tamaño (en bytes) de la tabla. Simplemente: tamaño

tabla = tamaño de la fila (promedio) * número de filas

La pregunta es, "lo grande que una tabla es demasiado grande"?

Cuestiones relacionadas