Tenga en cuenta: estoy respondiendo desde una perspectiva de SQL Server, por lo que menciono algunos conceptos específicos de SQL Server, pero creo que todos estos conceptos tienen equivalentes en otras plataformas RDBMS principales, con beneficios y limitaciones similares.
Probablemente también continuaré editando esta respuesta mientras pienso en otros posibles pros / contras.
Bueno, realmente depende del esquema, el volumen, etc. ¿Qué es exactamente el almacenamiento de una tienda? ¿En qué se diferencia de almacenar datos sobre 50,000 gatos o 50,000 productos o 50,000 nueces de ala?
Hay varias razones (aparte del aspecto del tamaño por sí solo) por las que es posible que no desee almacenar datos para 50,000 clientes diferentes en una sola base de datos, si de hecho los datos pueden ser completamente segregados por el cliente (sin incluir tablas de búsqueda como códigos postales o tablas específicas de la aplicación, que podrían ir a una única base de datos central):
Si un cliente crece más la aplicación, no hay manera fácil de extraer sólo sus datos y moverlo a otra instancia, servidor, etc., para escalar, a menos que se planifica con antelación y partición en algo parecido CustomerIDy tienen 50.000 grupos de archivos (que está limitado de todas formas, 15,000 particiones , o 1,000 si tienes una versión anterior de SQL Server y tener demasiados grupos de archivos puede ser desastroso ). También tenga en cuenta que la partición requiere Enterprise Edition.
si resulta que todos sus clientes son simplemente demasiado grandes para esta instancia, la ampliación significa obtener nuevo hardware y mover toda la base de datos allí (y posiblemente volver a hacerlo en el futuro).
eliminar un cliente puede ser igualmente doloroso, ya que tendrá que eliminar un porcentaje de las filas de tablas muy grandes, y eso no será barato.
probablemente tendrá una amplia distribución de datos de clientes (un cliente con mil millones de filas, otro cliente con 5,000). Esto puede llevar a cosas como la detección de parámetros y el rendimiento perjudicial que implica la cardinalidad y la calidad del plan (ya que probablemente reutilizará los mismos planes para las mismas consultas en conjuntos de datos muy diferentes).
Todos sus clientes están sujetos a los mismos planes de SLA y HA / DR. O tiene toda la base de datos en modo de recuperación completa con copias de seguridad de registro de n minutos, o está en modo simple y confía en copias de seguridad completas + diferenciales. Si tiene que revertir debido a un error del cliente, o necesita recuperar la base de datos a un punto en el tiempo, eso afecta a cada cliente.
existe la posibilidad de errores en la recuperación de datos: errores en las cláusulas donde, por ejemplo, podrían provocar que un cliente vea los datos de otro cliente o todos los datos de los demás clientes.
puede haber implicaciones legales (algunas compañías tendrán requisitos estrictos para que usted no coloque sus datos en la misma base de datos que cualquier otra compañía, y particularmente la de sus competidores).
Si la seguridad de los datos de cualquier cliente es importante, lograrlo es mucho más fácil usando la separación de la base de datos que la separación dentro de una tabla.
Algunas ventajas de tener a cada cliente en una base de datos separada (o al menos tener múltiples bases de datos, cada una para un grupo de clientes):
- en términos de tamaño, tomará aproximadamente el mismo tamaño en el disco.
- escalar es más fácil, ya que puede mover una base de datos (o muchas) a un servidor diferente.
- eliminar un cliente y todos sus datos equivale aproximadamente a
DROP DATABASE.
- está utilizando más memoria para los planes (o tiene menos planes en caché por cliente), pero al menos esos planes son relevantes para los datos en sus respectivas bases de datos y son menos propensos a problemas de análisis de estadísticas / parámetros.
- puede tener fácilmente diferentes SLAs y planes de DR, colocando algunas bases de datos completas y otras de manera simple. También revertir o restaurar a un punto en el tiempo solo afecta a ese cliente.
- puede colocar fácilmente diferentes bases de datos (por ejemplo, sus clientes de alta prioridad) en E / S más rápidas. Podría hacerlo en una única base de datos con grupos de archivos, pero es mucho más difícil de administrar (al menos en mi humilde opinión).
Algunos inconvenientes:
- aparte del tamaño, es probable que no desee tener 50,000 bases de datos en una sola instancia de SQL Server, por lo que esto probablemente signifique escalar a varios servidores.
- el tiempo de inicio aumenta porque hay una sobrecarga inherente al iniciar cada base de datos.
- la aplicación tiene que ser un poco más inteligente; en lugar de solo tener CustomerID en la cláusula where, debe conectarse dinámicamente a la base de datos de CustomerID. Esto no es difícil con un nivel medio adecuado, pero es un cambio.
- Sí, tiene muchas copias de las mismas tablas y procedimientos, pero el código y el esquema son idénticos en todas las bases de datos, solo los datos son diferentes. Entonces, implementar cambios de código / esquema ahora es solo un bucle en lugar de una sola ejecución.
- el mantenimiento es un poco diferente cuando se administran 50,000 bases de datos; nuevamente, el tamaño general es más o menos el mismo, pero el proceso tiene que cambiar; no se puede simplemente desfragmentar / reindexar / respaldar todas las 50,000 bases de datos a la vez. Dicho esto, en mi trabajo anterior gestioné instancias con 500-1,000 bases de datos idénticas, y la diferencia entre administrar 3 bases de datos idénticas y 750 bases de datos idénticas es simplemente el tiempo que lleva.