Una base de datos contra muchas bases de datos

Sé que la pregunta se ha hecho muchas veces pero me gustaría obtener una respuesta para mi caso.Una base de datos contra muchas bases de datos

Estoy trabajando en una aplicación web que permitirá a mis clientes administrar sus clientes, cobros, facturas, reservas, un sitio web y muchas otras cosas. Estoy usando MySQL y una base de datos con aproximadamente 30 tablas.

Me gustaría que mi solución sea capaz de manejar alrededor de 100.000 clientes o más. Las necesidades de mis clientes serán muy diferentes. Desde 100 inserciones por año para una, hasta 1000 inserciones por día para otra.

Por ahora estoy usando una base de datos (pero todavía estoy en desarrollo) donde cada tabla tiene un campo de cuenta. Creé una capa de modelo para acceder a los datos que anexan automáticamente la cuenta a cada consulta (DÓNDE guid = 1 convertido en WHERE cuenta = X AND guid = 1). Esto funciona muy bien y es realmente fácil de mantener, pero me preocupa el hecho de mezclar los datos de mis clientes. Tenga en cuenta que estoy usando una identificación incremental en lugar de un GUID.

Mi pregunta es, ¿debería continuar haciendo cosas como esta o debería crear una base de datos por cliente?

Fuente

2011-11-28 Nicolas BADIA

¿Te * * tener 100.000 clientes en este momento? De lo contrario, se optimiza de manera previa tratando de tenerlo como requisito. –

Y la respuesta a su pregunta es un gran "depende". Sin más detalles sobre los detalles, no hay nada que pueda decirse. –

¿Qué más detalles quieres? Como digo, todavía estoy en desarrollo, así que tengo pocos probadores. Pero estaba pensando que este tipo de cosas deberían pensar antes de abrir mi aplicación al público. Me equivoco ? –

Estás viendo una base de datos de varios inquilinos. Las soluciones multi-tenant van desde una base de datos por cliente (nada compartido) a una fila por cliente (todo compartido).

"Nada compartido" es el más caro por cliente. Un gran número de clientes implica una gran cantidad de servidores. La recuperación de desastres del cliente es simple y directa. "No se compartió nada" reduce la posibilidad de exponer accidentalmente los datos del cliente a casi cero.

"Todo compartido" es el menos costoso por cliente. Cada tabla tiene una columna que identifica a qué cliente pertenece una fila. La recuperación de desastres del cliente es muy complicada; tienes que restaurar filas individuales en cada tabla. "Compartido todo" es la arquitectura con mayor probabilidad de exponer accidentalmente los datos del cliente.

Microsoft tiene un buen artículo en multi-tenant architecture. Su terminología es

base de datos independiente (no compartida)
esquema separada
esquema compartido (todo lo compartido)

Fuente

2011-11-28 08:20:43

bien escrito, también traté de informar esto, pero tu respuesta es excelente. –

Gracias por la respuesta y el artículo. Me parece que un esquema separado es la mejor opción para mí, pero, por lo que sé, mysql no lo permite.Así que ahora tengo 3 opciones, me quedo así, me muevo a PostgreSQL (que me parece una buena opción), o uso una base de datos separada (parece una mala opción ya que no espero hacer un desarrollo específico para un cliente) . Algún consejo ? –

Personalmente, prefiero trabajar con PostgreSQL que con MySQL. Pero más servidores web ofrecen MySQL que PostgreSQL. Una base de datos MySQL no es muy diferente de un esquema de PostgreSQL. Ambos proporcionan un espacio de nombres, y MySQL puede realizar consultas en bases de datos como las consultas PostgreSQL en todos los esquemas. PostgreSQL no admite consultas directas en dos bases de datos. –

Una base de datos contra muchas bases de datos

Respuesta

Cuestiones relacionadas