¿Pros y contras de usar muchos esquemas en PostgreSQL en lugar de solo uno?

Para una aplicación SAAS grande (respaldada por PostgreSql 9.4), con más de 300,000 cuentas (y en crecimiento), ¿cuáles son los pros y los contras de usar un esquema por cuenta para dividir los datos frente a poner todos los datos en un esquema y usar claves externas para particionarlo en las consultas?

Sé que en el pasado pg_dump era dolorosamente lento cuando trabajaba con muchos esquemas, pero no estoy seguro de si ese es el caso hoy. También sé que cualquier cambio en la estructura de la base de datos tendrá que hacerse en todos los esquemas. Y sé que, en el lado positivo, mover un esquema de un servidor físico a otro es fácil, así como restaurar un esquema desde la copia de seguridad, sin mencionar que tiene sentido particionar los datos de esa manera.

Entonces, ¿cuáles son los pros y los contras que me estoy perdiendo?

— Harel
fuente

Ninguno de los dos se ve bien. Es difícil administrar una sola tabla enorme ("crecimiento vertical") y también es difícil administrar una gran cantidad de esquemas ("crecimiento horizontal").

— Daniel Vérité

Estoy reconstruyendo un sistema antiguo que tiene esa cantidad de cuentas (e incluso una cantidad mayor de usuarios). Está utilizando un enfoque compartido (usando mySql) y funciona bien en lo que respecta al rendimiento. Mi preocupación es mantener ese nivel de rendimiento pero agregarle capacidad de mantenimiento.

— Harel

@Harel Tengo curiosidad, ¿lo intentaste con esquemas de 400k o cambiaste a otra arquitectura / tecnología?

— sthzg

Renuncié a la idea después de profundizar en ella. La cantidad de esquemas que iba a crear derrotaría cualquier uso práctico de esto. Fui con el campo de identificación de la cuenta antigua en cada registro. Sin embargo, lo que sí hice fue eliminar los identificadores numéricos de incremento automático a favor de los UUID, lo que significa que puedo tomar una cuenta completa de un db a otro con bastante facilidad sin tener que preocuparme por romper la integridad.

— Harel

Obviamente, se trata de las mismas tablas en cada esquema de usuario. ¿Has considerado la herencia para esto? Puede darle lo mejor de ambos mundos para algunos casos de uso. También hay algunas limitaciones . Puede tener un esquema separado para cada usuario y aún así buscar todas las tablas de usuarios a la vez de manera muy conveniente.

Relacionado:

Aparte de eso, debe mencionarse al menos otorgar / revocar privilegios, lo cual es mucho más simple con esquemas separados.

— Erwin Brandstetter
fuente

Investigaré la herencia. Sin embargo, mi preocupación es con la escala aquí. En todas partes que leo, la gente habla de la estrategia de esquemas de inquilinos múltiples, pero se refiere a decenas, cientos o miles de esquemas. Un lugar menciona esquemas de 20K. La pregunta es: ¿son demasiados esquemas de 400K? ¿Causará la locura de un descriptor de archivos y matará al servidor? ¿Lo estoy empujando?

— Harel

Además, tenía la intención de mantener los datos del inquilino (cuentas y usuarios) en el esquema público, mientras mantenía los esquemas como datos de usuario reales. Esos datos no se comparten, y nunca se compartirán entre esquemas.

— Harel

La herencia no me ayudará aquí, no lo creo. El enfoque compartido utiliza un solo esquema con claves foráneas obligatorias para el usuario o inquilino, por lo que no se gana nada al heredar, me temo.

— Harel

De este artículo influitive.io/… creo que el modo de esquema múltiple no es una buena manera para los inquilinos de gran número. La columna tenant_id (la forma antigua) es mejor.

— Xiaohui Zhang