sql-server - tablas - sql server query to html table
Diseño de la base de datos: ¿una mesa enorme o mesas separadas? (13)
¿Es esta una mesa plana única (sin modelo en particular)? Normalmente en almacenes de datos, o bien tiene un modelo de datos normalizado (al menos una tercera forma normal, generalmente en un modelo de relación de entidad) o tiene datos dimensionales (método o variaciones de Kimball), generalmente tablas de hechos con tablas de dimensiones asociadas en un conjunto de estrellas).
En ambos casos, los índices juegan un papel importante, y las particiones también pueden ayudar a que las consultas funcionen (pero las particiones generalmente no se tratan de rendimiento, sino de que el mantenimiento puede agregar y soltar particiones rápidamente) en conjuntos de datos muy grandes, pero realmente depende del orden de agregación y los tipos de consultas.
Actualmente estoy diseñando una base de datos para usar en nuestra compañía. Estamos utilizando SQL Server 2008. La base de datos contendrá los datos recopilados de varios clientes. El objetivo de la base de datos es adquirir números de referencia agregados sobre varios clientes.
Recientemente, me ha preocupado el hecho de que una mesa en particular se hará muy grande. Cada cliente tiene aproximadamente 20,000,000 de filas de datos, y pronto habrá 30 clientes en la base de datos (si no más). Se realizarán muchas consultas en esta tabla. Ya estoy notando problemas de rendimiento y bloqueos temporales de los usuarios.
Mi pregunta, ¿podremos manejar esta tabla en el futuro, o es mejor dividir esta tabla en tablas más pequeñas para cada cliente?
Actualización : Ha pasado aproximadamente medio año desde que creamos las tablas por primera vez. Siguiendo los consejos a continuación, creé un puñado de tablas enormes. Desde entonces, he estado experimentando con índices y he decidido un índice agrupado en las dos primeras columnas (código de hospital y código de departamento) en el que habríamos particionado la tabla si hubiéramos tenido Enterprise Edition. Esta configuración funcionó bien hasta hace poco, como predijo Galwegian, los problemas de rendimiento están surgiendo. Reconstruir un índice lleva años, los usuarios se bloquean mutuamente, las consultas suelen tardar más de lo que deberían, y para la mayoría de las consultas vale la pena copiar primero la parte relevante de los datos en una tabla temporal, crear índices en la tabla temporal y ejecutar el consulta. Así no es como debería ser. Por lo tanto, estamos considerando comprar Enterprise Edition para el uso de tablas particionadas. Si la compra no puede continuar, planeo usar una solución alternativa para lograr particiones en la Edición estándar .
Comience con una tabla grande y luego aplique las capacidades de partición de tabla de 2008 cuando corresponda, si el rendimiento se convierte en un problema .
Como también etiquetó su pregunta como ''datawarehouse'', asumo que sabe algunas cosas sobre el tema. Dependiendo de sus objetivos, puede optar por un esquema en estrella (un modelo multidemensional con un hecho y tablas de dimensiones). Almacene todos los datos de cambio rápido en 1 tabla (por tema) y los datos de lento en otras tablas de dimensión / ''copo de nieve''.
Otra opción es el método DataVault de Dan Lindstedt. Lo cual es un poco más complejo pero te proporciona una flexibilidad total.
En una base de datos diseñada correctamente, no es una gran cantidad de registros y el servidor SQl debería manejarlo con facilidad.
Una mesa individual dividida suele ser la mejor manera de ir. Intentar mantener tablas independientes de clientes es muy costoso en términos de tiempo y esfuerzo, y mucho más relacionado con los errores.
También examine sus consultas actuales si tiene problemas de rendimiento. Si no cuenta con una indexación adecuada (¿indexó, por ejemplo, los campos de la clave externa?) Las consultas serán lentas, si no tiene consultas rescatables serán lentas si utilizó subconsultas o cursores correlacionados, serán lentos. ¿Devuelve más datos de los estrictamente necesarios? Si seleccionó * en cualquier parte de su código de producción, deshágase de él y solo devuelva los campos que necesita. Si utilizó vistas que llaman a vistas que llaman a vistas o si usó la tabla EAV, tendrá indicadores de rendimiento en este nivel. Si permitía que un marco de trabajo autogenere el código SQl, es posible que tenga consultas que no cumplan con los requisitos. Recuerda que Profiler es tu amigo. Por supuesto, también podría tener un problema de hardware, necesita un servidor dedicado de gran tamaño para esa cantidad de registros. No funcionará ejecutar esto en su servidor web o en una pequeña caja.
Sugiero que necesites contratar un dba profesional con experiencia de ajuste de rendimiento. Es algo bastante complejo. Las bases de datos diseñadas por los programadores de aplicaciones a menudo tienen malos resultados cuando obtienen una cantidad real de usuarios y registros. La base de datos DEBE diseñarse teniendo en cuenta la integridad, el rendimiento y la seguridad de los datos. Si no hiciste eso, los cambios de tenerlos son realmente escasos.
La división de tablas por motivos de rendimiento se denomina sharding . Además, un esquema de base de datos puede ser más o menos normalizado. Un esquema normalizado tiene tablas separadas con relaciones entre ellos, y los datos no están duplicados.
Mantenga una tabla: 20M filas no es muy grande, y los clientes no son exactamente el tipo de tabla que puede ''archivar fácilmente'', y la suma de buscar varias tablas para encontrar un cliente no vale la pena el esfuerzo (SQL es es probable que sea mucho más eficiente en la búsqueda de BTree que su propia invención)
Sin embargo, tendrá que analizar los problemas de rendimiento y bloqueo: esto evitará que su base de datos escale.
Partioning es definitivamente algo para mirar. Tenía una base de datos que tenía 2 tablas fragmentadas. Cada tabla contenía alrededor de 30-35 millones de registros. Desde entonces, he fusionado esto en una gran tabla y he asignado algunos buenos índices. Hasta ahora, no he tenido que particionar esta tabla, ya que está funcionando bien, pero sigo teniendo en cuenta las particiones. Una cosa que he notado, en comparación con cuando se fragmentaron los datos, y esa es la importación de datos. Ahora es más lento, pero puedo vivir con eso ya que la herramienta Importar puede volver a escribirse; o)
Se supone que los datawarehouses son grandes (la clave está en el nombre). Veinte millones de filas son más o menos medianas según los estándares de almacenamiento, aunque seiscientos millones se pueden considerar de gran tamaño.
Lo que hay que tener en cuenta es que las tablas tan grandes tienen una física diferente, como los agujeros negros. Así que ajustarlos requiere un conjunto diferente de técnicas. La otra cosa es que los usuarios de un datawarehouse deben entender que están tratando con grandes cantidades de datos, por lo que no deben esperar una respuesta por debajo del segundo (o de hecho, por debajo del minuto) para cada consulta.
El particionamiento puede ser útil, especialmente si tiene demarcaciones claras, como, como en su caso, CLIENTE. Debe tener en cuenta que el particionamiento puede degradar el rendimiento de las consultas que cortan el grano de la clave de particionamiento. Entonces no es una bala de plata.
Si está en el servidor MS SQL y desea mantener la tabla única, la partición de la tabla podría ser una solución.
Supongo que tiene su base de datos debidamente normalizada. No debería ser un problema tratar con el volumen de datos al que se refiere en una sola tabla en SQL Server; lo que creo que debes hacer es revisar tus índices.
También puede crear tablas suplementarias que contengan detalles ya calculados sobre información histórica si hay consultas comunes.
Una mesa, luego preocúpate por el rendimiento. Es decir, suponiendo que recopile la misma información exacta para cada cliente. De esa manera, si tiene que agregar / eliminar / modificar una columna, solo lo está haciendo en un solo lugar.
Una tabla y usa la partición de la tabla.
Creo que el consejo de usar NOLOCK no está justificado en base a la información proporcionada. NOLOCK significa que obtendrá resultados inexactos y poco fiables de sus consultas (lecturas sucias y fantasmas). Antes de usar NOLOCK, debe estar seguro de que no va a ser un problema para sus clientes.