¿Puede ser una buena idea crear una nueva tabla para cada cliente de una aplicación web?

10

Esto es semi-hipotético, y como no tengo experiencia en el manejo de tablas de bases de datos masivas, no tengo idea de si esto es horrible por alguna razón. Sobre la situación:

Imagine una aplicación basada en la web, digamos un software de contabilidad, que tiene 20,000 clientes y cada cliente tiene más de 1000 entradas en una tabla. Son 20 millones de filas que, sin duda, pueden ralentizar las consultas complejas.

En un caso como este, ¿tiene más sentido crear una nueva tabla en la base de datos para cada cliente? ¿Cómo reaccionan las bases de datos al tener 20k (o más) tablas?

web-applications database-development

— Será
fuente

15

En términos generales, no, no tiene sentido tener una tabla (creo que realmente se refiere a la base de datos aquí) por cliente. 20 millones de filas son relativamente pequeñas para una tabla de base de datos. La velocidad de consulta en contra de eso no debería ser un problema, siempre y cuando la base de datos esté ajustada (indexada) correctamente y las consultas se unan correctamente. Cualquier beneficio que creas que obtendrías al separarlos se compensaría con la complejidad adicional de administrar 20,000 bases de datos individuales. Por ejemplo, ¿qué sucede cuando quieres cambiar la estructura de la tabla? ¡Ahora tienes que hacerlo 20,000 veces!

En el peor de los casos, si finalmente encuentra que el tamaño de la base de datos se está convirtiendo en un problema, siempre puede dividirlos en bases de datos separadas después.

— Gran maestro B
fuente

no, literalmente quise decir tablas dentro de la base de datos. No puedo imaginar una razón para crear una base de datos por cliente. Y si 20 millones de filas son pequeñas, ¿cuál es grande? ¿Y qué haces en ese punto?

— Se

1

@ChrisF, exactamente: hay muchos casos en los que la tecnología o el modelo comercial requieren DB por separado por cliente. Pero no puedo pensar en una razón para tablas separadas dentro del mismo DB.

— GrandmasterB

1

@GrandmasterB - Creo que @Will está haciendo la pregunta equivocada.

— ChrisF

1

@Will: si es posible, vaya a una reunión de Oracle User Group, o el equivalente para alguna otra base de datos de gama alta. Encontrará que sus ideas de "pequeño" y "grande" necesitan mucho reajuste. Me pasó a mi. Sugerencia: si cabe en un disco, no es grande para los estándares DBA.

— David Thornley

1

@Gorton, InnoDB generalmente se considera mejor por su confiabilidad y concurrencia, MyISAM por su velocidad. Por lo tanto, realmente necesita evaluar los diferentes motores de almacenamiento en función del uso esperado de la base de datos de su aplicación específica.

— GrandmasterB

5

Suena como una mala idea.

No intentes burlar a la base de datos con construcciones exóticas como esta. Los motores de bases de datos están diseñados con muchas optimizaciones para manejar grandes conjuntos de datos. Por ejemplo, lo que está describiendo suena terriblemente cercano a un intento de implementar índices manualmente. Simplemente use los índices proporcionados por el motor DB, se implementan mucho mejor de lo que probablemente pueda hacer por su cuenta, y no requerirá tanto mantenimiento.

Además, como regla general. Sugiero no diseñar una base de datos de una manera que requiera manipulación o creación de estructuras de bases de datos (tablas, campos) durante el uso normal de la aplicación. Hace que la optimización del rendimiento sea un obstáculo y, a menudo, lo obliga a otorgar demasiados permisos a los usuarios para realizar tareas de rutina que podrían crear agujeros de seguridad.

— JohnFx
fuente

Votaría una vez por cada uno de tus dos párrafos si me lo permiten.

— David Thornley

3

Aquí hay un artículo que siempre insto a las personas a leer, cuando hacen esta pregunta:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

— Mchl
fuente

No tenía idea de que una base de datos crea un archivo real por tabla = x

— Se

1

Esto podría depender del RDBMS real utilizado. MySQL hace eso (hasta tres archivos por tabla si usa MyISAM). Otros podrían no.

— Mchl

La versión empresarial de SQL Server lo hará si lo diseña de esa manera, pero no automáticamente.

— JeffO

Oracle definitivamente no hace eso.

— user281377

Oracle puede hacerlo, de la misma manera que SQL Server puede hacerlo, pero no puedo imaginar por qué alguna vez diseñaría su esquema para tener un archivo por tabla. Dividir una base de datos en varios archivos tiene sentido, pero no un archivo por tabla.

— Dean Harding

1

En mi humilde opinión, una sola tabla no debería ser un problema, así que no cree un problema donde no exista una, todavía. Hay muchas cosas que puede hacer para ayudar al rendimiento. Puede particionar una sola tabla en varios archivos según el ID de cliente o un campo de fecha para ayudar con IO. Su base de datos no tiene que realizar un seguimiento, optimizar y almacenar en caché 20,000 sentencias sql diferentes para cada consulta que necesite su sitio. Puede indexar por clientid. 20 mil clientes pueden pagar una gran cantidad de hardware.

Para este tipo de tabla, se podría usar un tipo NoSQL db.

Con 20K clientes, la base de datos puede no ser su eslabón más débil, entonces, ¿por qué introducir tanta complejidad?

— JeffO
fuente

`Puede particionar una sola tabla en varios archivos en función del ID de cliente o un campo de fecha para ayudar con IO. - No estoy seguro de lo que quiere decir con esto. Alguna aclaración?

— Se

Múltiples archivos en el sistema operativo. Un servidor puede hacer más lecturas / escrituras en muchos archivos en lugar de solo uno.

— JeffO

Supongo que quise decir: nunca he oído hablar de tal cosa, ¿dónde puedo encontrar más información sobre esto? :-) Pero iré a google ~

— Será el

msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx Puede encontrarse con problemas de rendimiento de la copia de seguridad si los índices están en archivos separados de las tablas que indexan (¿o quizás unidades?).

— JeffO

0

Ese es un mal enfoque.

Particione la tabla verticalmente, 2 servidores de bases de datos, uno para identificadores de usuario impares, y otro para pares debería funcionar bien (los datos no están relacionados entre los usuarios).

Ordene los datos por user_id y, si eso no es posible, obtenga una gran cantidad de discos RAM o SSD.

— Slawek
fuente