Una gran base de datos versus varios más pequeños

Tenemos una situación en la que podemos (A) desplegar instancias de una aplicación en una base de datos MySQL usando el prefijo de tabla o (B) usar diferentes bases de datos MySQL para cada instancia de la aplicación, por ejemplo,

Configurar un":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

El resultado final es una gran base de datos con muchas tablas.

Configuración "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

El resultado final son muchas bases de datos con algunas tablas.

En igualdad de condiciones (p. Ej., Cantidad de datos, número de instancias de aplicaciones, etc.), ¿cuáles son los pros y los contras de utilizar cualquiera de los enfoques? ¿Qué sería perjudicial para el rendimiento y el mantenimiento de la base de datos? La aplicación está basada en PHP 5, se ejecuta sobre Apache 2.x, y estamos ejecutando MySQL 5.x.

Muchas gracias por tu tiempo y pensamientos!

Ejecuté un sistema con la mejor parte de mil bases de datos, distribuidas en múltiples servidores. Todos tenían una estructura idéntica y estaban sincronizados con una base de datos de plantilla que estaba en cada una de las máquinas.

Esto me permitió la capacidad de migrar bases de datos de una base de datos a otra si una se sobrecargaba demasiado y, a medida que cambiaba la combinación de clientes, podía crear nuevas bases de datos en diferentes servidores para equilibrar la carga entre los servidores. Esta fue la mayor ventaja que obtuve del sistema, ya que tenía múltiples grandes trozos de estaño realizando múltiples consultas complicadas simultáneamente en los servidores separados.

Lo mejor de esto es que puede agregar servidores a la configuración a su propia velocidad, ya que cada servidor comienza a sobrecargarse, agregar otro a la mezcla, migrar algunos dbs al nuevo servidor y terminar con un buen conjunto equilibrado de carga de servidores. ¡Una forma realmente agradable y sencilla de agregar escala al sistema cuando sea necesario!

La razón por la que utilicé este enfoque en lugar del enfoque de una gran base de datos, fue el gran tamaño de la base de datos potencial que se habría creado ... cada una de las 1000 bases de datos tenía 200 tablas, y muchas de las tablas individuales dentro de cada una de las bases de datos comprendidas muchos cientos de millones de filas de datos!

Una única configuración de base de datos habría requerido que ciertas tablas (aproximadamente 8 de ellas) tuvieran miles de millones de filas de datos, y el tamaño total de la base de datos habría sido superior a 10Tb. Pudimos tener múltiples servidores con 5Tb de almacenamiento RAID 10, con muchas bases de datos en cada uno.

¡Eso es lo que yo haría! Espero que ayude a tomar decisiones ... :)

¿La aplicación que está creando es una aplicación SaaS? Si es así, le sugiero que considere un tercer enfoque: tener una base de datos, con una estructura común para todas las instancias de aplicación con una diferencia, agregue una columna userid / applicationid en todas las tablas. Esto reducirá en gran medida los costos de desarrollo / mantenimiento de su aplicación. En mi experiencia, este es uno de los mejores enfoques para almacenar datos de múltiples inquilinos.

Consulte también este excelente documento técnico de Microsoft sobre arquitectura de datos de múltiples inquilinos

También destaca las ventajas / desventajas de los enfoques que ha mencionado.

La configuración B es mucho más fácil de administrar

Cada uno se tablensienta en una carpeta diferente. Eso puede ser muy beneficioso si no desea probar los límites del sistema operativo .

Por ejemplo, mi empleador aloja MySQL para un sistema CRM de concesionarios de automóviles. El cliente tiene 800 concesionarios. Cada base de datos del concesionario tiene 160 tablas. Eso es 128,000 mesas.

• Bajo la Configuración A, las 128,000 tablas se ubicarían en una base de datos.
• En Configuración B, cada conjunto de 160 tablas se encuentra en una subcarpeta en / var / lib / mysql.

Desde la perspectiva del sistema operativo y su capacidad para manejar i-nodos (o tablas FAT para Windows), lo que incluye tener un número máximo de archivos por carpeta:

• En la Configuración A, se preocuparía por 128,000 archivos en una carpeta. ¿Puede su sistema operativo admitir tantos archivos en una sola carpeta?
• En Configuración B, no hay tal preocupación.

Si tuvo que modificar las estructuras de la tabla usando ALTER TABLEu otro DDL:

• En la Configuración A, tendría que escribir el DDL necesario usando PHP (o scripts MySQL especializados) contra el nombre de la tabla específica y las consultas correspondientes antes de acceder y realizar cambios
• En Configuración B, conéctese a la base de datos correcta, luego acceda a la misma tabla con nombre cada vez. El paradigma de acceso siempre estaría limpio:
  • Base de datos específica
  • Carpeta específica debajo /var/lib/mysql
  • Tablefic específico.

Si desea colocar diferentes bases de datos en diferentes discos:

• En la configuración A, los enlaces simbólicos para cada tabla movida a un disco separado solo exacerbarán el problema del "número de inodos en una carpeta". La E / S de disco y el acceso general a la tabla complican más y aumentan la carga general del servidor ya .frmque se accede repetidamente a los archivos.
• En Configuración B, simplemente mueva una carpeta de base de datos completa a un montaje de datos separado. La E / S de disco se puede distribuir bajo demanda.
• CAVEAT: Muy desanimado por InnoDB

Hablando metafóricamente, ¿cuál preferirías tener?

• Un gigantesco apartamento con un dormitorio, un baño y una cocina (SetupA)
• múltiples apartamentos, cada uno con su propio dormitorio, baño y cocina (SetupB)

Cuando se trata de arreglar un radiador en un apartamento:

• Con la Configuración A, todos los inquilinos pueden ser incómodos y deben participar porque tiene que hablar con los inquilinos afectados frente a todos como si fuera asunto de todos.
• Con la configuración B, además de escuchar algunos golpes en la pared o en las tuberías, los inquilinos pueden continuar con su vida privada
• Esta lista y sus metáforas pueden seguir y seguir

IHMO Aunque los presupuestos pueden ser una fuerza impulsora para las decisiones de diseño / infraestructura, estaría fácilmente a favor de separar las bases de datos por cliente.

También tengo un producto SaaS y uso la misma configuración que mencionó Dave Rix.

Cada cliente tiene su propia base de datos.

Haría algunas sugerencias más:

• Debe tener un "controlador" de base de datos con equilibrio de carga (maestro-maestro), que almacene la ubicación de la base de datos (ip), el nombre de la base de datos y el nombre del cliente. Este controlador es donde su aplicación sabe dónde está la base de datos de cada cliente.

• Su aplicación puede estar en cualquier lugar que desee: puede tener bases de datos para muchos centros de datos en todo el mundo.

• Su aplicación puede crecer tanto como desee. Si se trata de un Web SaaS, puede crear una granja de servidores web con equilibrio de carga que apunte a cada base de datos, tan pronto como inicie sesión el cliente.

• Puede crear VIEW / Base de datos personalizada para algunos clientes, sin afectar a otros. Eso es importante si intenta ofrecer personalización como parte de su negocio.

• Puede configurar dos granjas web + granjas de bases de datos: una para "EDGE" y otra para versiones "ESTABLES". Luego, necesitará tener un pequeño grupo de clientes dispuestos a probar cosas y confirmar que todo funciona como se esperaba (en otras palabras, garantía de calidad [QA]), antes de presentar una solicitud a todos sus clientes.

• Debe tener un trabajo de respaldo automatizado por base de datos al menos una vez al día.

• Debería tener otro servidor para hacer la replicación. Un mismo host puede replicar muchas bases de datos (use diferentes puertos para cada servidor en el mismo host) si no puede permitirse la misma cantidad de servidores host "maestros" y "esclavos".

  Por ejemplo, 5 servidores maestros + 1 servidor esclavo con 5 bases de datos que se ejecutan en diferentes puertos, solo tienen RAM suficiente para hacerlo.

• Debe hacer una herramienta de "migración" para mover una base de datos a otro servidor cuando lo desee.

• Debe migrar clientes VIP a un servidor de base de datos más seguro / disponible para mantener sus ingresos protegidos. Recuerde, muchas veces el 20% de los clientes representan el 80% de sus ingresos. Cuidar de clientes especiales.

• Debe tener un recopilador de "basura" de copia de seguridad y eliminación, para hacer una "última copia de seguridad" y eliminar la base de datos cuando un cliente abandone su empresa.

• Debe tener una imagen de base de datos donde exporte y use para nuevas cuentas.

• Debe tener una herramienta de parcheo de la base de datos para aplicar nuevos parches a las cuentas existentes.

• Mantenga versiones de todos sus parches SQL, utilizando una herramienta de control de versiones como subversion o git y cree su propia numeración también. xxx-4.3.0.sql: a veces el parcheo sale mal y debes saber cómo recuperar / completar la tarea de parcheo.

Bueno, esto es todo lo que hago en mi empresa con un producto que tiene aproximadamente 5k bases de datos con aproximadamente 600 tablas cada una.