Diseño de la base de datos: ¿una gran mesa o mesas separadas?

Question

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 volverá 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: Ahora ha sido aproximadamente la mitad de un año desde que se creó primero las tablas. Siguiendo los consejos a continuación, creé un puñado de tablas enormes. Desde entonces, he sido experimenting with indexes 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 realizarse, planeo usar un workaround to accomplish partitioning in Standard Edition.

Answer 1

comenzar con una mesa grande, y luego se aplican de 2008 la partición de tablas capacidades en su caso, si el rendimiento convierte en un problema.

Answer 2

Una tabla, luego preocúpese 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.

Answer 3

Tablas de separación por motivos de rendimiento se llama 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.

Answer 4

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.

Answer 5

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

Answer 6

Si está en el servidor MS SQL y desea mantener la tabla única, la partición de tablas podría ser una solución.

Answer 7

Dado que ha etiquetado su pregunta como 'datawarehouse' también supongo 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.

http://danlinstedt.com/category/datavault/

Answer 8

Mantener una mesa - filas 20M no es enorme, y los clientes no son exactamente el tipo de tabla que puede fácilmente 'archive off' y el aggrevation de buscar varias tablas para encontrar a un cliente no vale la pena el esfuerzo (es probable que SQL sea mucho más eficiente en la búsqueda 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.

Answer 9

También puede crear tablas suplementarias que contengan detalles ya calculados sobre información histórica si hay consultas comunes.

Answer 10

Partioning es definitivamente algo a tener en cuenta. 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)

Answer 11

Una tabla y use la partición de la tabla.

Creo que los consejos para usar NOLOCK no están justificados según 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.

Answer 12

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 opción. 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.

Le sugiero que necesite contratar un dba profesional con experiencia de ajuste del 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.

Answer 13

¿Se trata de 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 no son sobre rendimiento sino sobre mantenimiento y pueden agregar particiones rápidamente) sobre datos muy grandes conjuntos, pero realmente depende del orden de agregación y los tipos de consultas.