MySQL: ¿Hay muchas tablas o muchas bases de datos?

Question

Para un proyecto que tenemos un montón de datos que siempre tienen la misma estructura y no están vinculados entre sí. Hay dos enfoques para guardar los datos:

• Creación de una nueva base de datos para todas las piscinas (unos 15-25 mesas)
• Creación de todas las tablas en una base de datos y se diferencian las piscinas por los nombres de tabla.

¿Cuál es más fácil y más rápido de manejar para MySQL?

EDIT: No estoy interesado en cuestiones de diseño de bases de datos, solo estoy interesado en cuál de las dos posibilidades es más rápida.

EDIT 2: Intentaré dejarlo más claro. Como dijimos, tendremos datos, donde algunas de las fechas raramente pertenecen juntas en diferentes grupos. Poner todos los datos de un tipo de una tabla y su vinculación con una identificación de la piscina no es una buena idea:

• Es difícil de copia de seguridad/suprimir una agrupación específica (y esperamos que nos estamos quedando sin claves primarias después de un tiempo (incluso cuando se usa big int))

Así que la idea es crear una base de datos para cada grupo o crear muchas tablas en una base de datos. El 50% de las consultas en la base de datos será simple inserts. 49% será un simple selects en una clave principal.

La pregunta es, ¿qué es más rápido de manejar para MySQL? Muchas tablas o muchas bases de datos?

Answer 1

No debe haber una diferencia de rendimiento significativa entre varias tablas en una única base de datos frente a varias tablas en bases de datos separadas.

En MySQL, las bases de datos (el estándar SQL usa el término "esquema" para esto) sirven principalmente como espacio de nombres para las tablas. Una base de datos tiene solo algunos atributos, p. el conjunto de caracteres predeterminado y la intercalación. Y ese uso de GRANT hace que sea conveniente controlar los privilegios de acceso por base de datos, pero eso no tiene nada que ver con el rendimiento.

Puede acceder a tablas en cualquier base de datos desde una única conexión (siempre que estén administradas por la misma instancia de MySQL Server). Solo tiene que calificar el nombre de la tabla:

SELECT * FROM database17.accounts_table; 

Esto es puramente una diferencia sintáctica. No debería tener ningún efecto en el rendimiento.

En cuanto al almacenamiento, no puede organizar tablas en un archivo por base de datos como especula @Chris. Con el motor de almacenamiento MyISAM, siempre tiene un archivo por tabla. Con el motor de almacenamiento InnoDB, o bien tiene un único conjunto de archivos de almacenamiento que amalgaman todas las tablas, o bien tiene un archivo por tabla (esto está configurado para todo el servidor MySQL, no por base de datos). En cualquier caso, no existe ventaja de rendimiento o desventaja para crear las tablas en una base de datos única frente a muchas bases de datos.

No hay muchos parámetros de configuración de MySQL que funcionen por base de datos. La mayoría de los parámetros que afectan el rendimiento del servidor abarcan todo el servidor.

En cuanto a las copias de seguridad, puede especificar un subconjunto de tablas como argumentos para el comando mysqldump. Puede ser más conveniente hacer una copia de seguridad de conjuntos lógicos de tablas por base de datos, sin tener que nombrar todas las tablas en la línea de comandos. Pero no debería afectar el rendimiento, solo es conveniente para usted al ingresar el comando de respaldo.

Answer 2

¿Por qué no crear una sola tabla para realizar un seguimiento de sus grupos (con un PoolID y PoolName como columnas, y cualquier otra cosa que quiera rastrear) y luego en sus tablas 15-25 agregaría una columna en todos ellos que serían una clave externa de vuelta a su mesa de billar para que sepa a qué grupo pertenece ese registro en particular.

Si no desea mezclar los datos de esa manera, le sugiero que haga varias bases de datos. Crear múltiples tablas para la misma funcionalidad hace que mi sentido de araña se estremezca.

Answer 3

Si no desea un conjunto de tablas con poolID poolname como sugiere TheTXI, use bases de datos separadas en lugar de varias tablas que hagan lo mismo.

De esta forma, restringe la variación entre el acceso de diferentes grupos a la declaración inicial de "usar base de datos", no tendrá que volver a codificar sus SELECT cada vez, ni tendrá sql dinámico.

Las otras ventajas de este enfoque son:

• Fácil de copia de seguridad/restauración
• Fácil arranque/parada de una instancia de base de datos.

Las desventajas son:

• un poco más de trabajo de administración, pero no mucho.

No sé cuál es su aplicación, pero realmente realmente lo pienso cuidadosamente antes de crear todas las tablas en una base de datos. De esa manera, la locura miente.

Editar: Si el rendimiento es lo único que le preocupa, debe medirlo. Tome un conjunto representativo de consultas y mida su desempeño.

Edición 2: La diferencia en el rendimiento para una sola consulta entre el modelo de muchas tablas/muchas bases de datos será insignificante. Si tiene una base de datos, puede sintonizarla. Si tiene muchas bases de datos, puede sintonizarlas al máximo.

Mi (nuestro? - no se puede hablar por nadie más) punto es que, para bases de datos bien ajustadas, prácticamente no habrá diferencia en el rendimiento entre las tres opciones (poolid en tabla, tablas múltiples, múltiples bases de datos), para que pueda elegir la opción que sea más fácil para usted, a corto y largo plazo.

Para mí, la mejor opción es todavía una base de datos con poolId, como sugirió TheTXI, luego múltiples bases de datos, dependiendo de sus necesidades (principalmente de administración). Si necesita saber exactamente cuál es la diferencia en el rendimiento entre dos opciones, no podemos darle esa respuesta. Debes configurarlo y probarlo.

Con múltiples bases de datos, es fácil utilizar hardware para mejorar el rendimiento.

Answer 4

No estoy muy seguro de entender por completo su situación. ¿Desea que todas las agrupaciones usen las mismas tablas, pero solo difieren en una clave distintiva? ¿O desea conjuntos de tablas separadas dentro de la base de datos única, con un sufijo en cada tabla para distinguir las agrupaciones?

De cualquier manera, debe tener múltiples bases de datos por dos razones principales. La primera es que si tiene que cambiar el esquema en un grupo, no afectará a los demás.

El segundo, si sube su carga (o por cualquier otra razón), puede mover las agrupaciones en máquinas físicas separadas con servidores de bases de datos nuevos.

Además, el acceso de seguridad a un servidor de base de datos se puede bloquear más estrictamente.

Todas estas cosas se pueden realizar sin necesidad de bases de datos separadas, pero la separación hará que todo esto sea más fácil y reducirá la complejidad de tener que rastrear mentalmente las tablas en las que desea operar.

Answer 5

No sé mysql muy bien, pero creo que tendré que dar la respuesta de rendimiento estándar: "Depende".

Algunos pensamientos (que solo trabajan con un rendimiento de mantenimiento, no de diseño/base de datos):

• Creación de una nueva base de datos significa un archivo separado (o archivos) en el sistema de archivos. Estos archivos podrían colocarse en sistemas de archivos diferentes si el rendimiento de uno necesita ser separado de los demás, etc.
• Una nueva base de datos probablemente manejará el almacenamiento en caché de manera diferente; p.ej. Todas las tablas en un DB significan un caché compartido para el DB, mientras que dividir las tablas en bases de datos separadas significa que cada base de datos puede tener un caché separado [obviamente todas las bases de datos compartirán la misma memoria física para el caché, pero puede haber un límite por base de datos, etc.].
• Relacionado con los archivos separados, esto significa que si uno de sus conjuntos de datos se vuelve más importante que los demás, puede retirarse fácilmente a un nuevo servidor.
• La separación de las bases de datos tiene la ventaja adicional de permitirle implementar las actualizaciones una a la vez más fácilmente que con la base de datos única.

Sin embargo, al tener varias bases de datos, el servidor probablemente usará más memoria (ya que tiene múltiples cachés). Estoy seguro de que hay más "contras" para el enfoque de múltiples bases de datos, pero estoy dibujando un espacio en blanco ahora.

Supongo que recomendaría el enfoque de varias bases de datos. Obviamente, esto es solo con la comprensión de que puede existir una mejor forma de manejar el diseño de la base de datos, sea lo que sea que realmente esté haciendo.

Answer 6

Dadas las restricciones que ha impuesto, preferiría girar más tablas en la base de datos existente, en lugar de tener que conectarme a múltiples bases de datos. La gestión de las cadenas de conexión TEND es más difícil, además de gestionar las diferentes optimizaciones de base de datos que pueda tener.

Answer 7

FTR, en circunstancias normales tomaría el enfoque descrito por TheTXI.

Sin embargo, en respuesta a su pregunta específica, he encontrado que depende del uso. (Cop out Lo sé, pero escúcheme.)

Una única base de datos es probablemente más fácil. Tendrá que preocuparse por una sola conexión y aún deberá especificar tablas. Múltiples bases de datos podrían, bajo ciertas condiciones, ser más rápidas.

Si yo fuera, probaría ambas. No hay forma de que podamos darle una respuesta útil.

Answer 8

Diferir los grupos por nombre de tabla o ponerlos en bases de datos separadas es casi lo mismo. Sin embargo, si tiene muchas tablas en una base de datos, MySQL tiene que cargar la información de la tabla y hacer una comprobación de seguridad en todas esas tablas al iniciar sesión/conectarse.

Como mencionan otros, las bases de datos separadas le permitirán cambiar las cosas y crear optimizaciones específicas para un grupo determinado (es decir, tablas comprimidas). Es una sobrecarga de administración adicional, pero hay considerablemente más flexibilidad.

Además, siempre puede "agrupar" las tablas que están en bases de datos separadas mediante el uso de tablas fusionadas o federadas para simplificar las consultas si es necesario.

En cuanto a la falta de claves principales, siempre puede utilizar una clave primaria compuesta si está utilizando tablas MyISAM. Por ejemplo, si tiene un campo llamado groupCode (cualquier tipo) y otro llamado sequenceId (autoincremento) y cree su clave principal como groupCode + sequenceId. La secuenciaId se incrementará en función de la siguiente ID única dentro del conjunto de códigos de grupo. Por ejemplo: AAA AAA 1 acreditación 1 AAA 3 CCC AAA acreditación ...

Aunque con tablas de gran tamaño que tiene que tener cuidado con el almacenamiento en caché y asegúrese de que el sistema de archivos está utilizando maneja archivos de gran tamaño.

Answer 9

En la situación que describe, la experiencia me ha llevado a creer que encontrará las bases de datos separadas para ser más rápidas cuando tiene una gran cantidad de grupos.

Sin embargo, aquí hay un principio general muy importante que observar: No piense qué tan rápido será, perfíllo.