Matriz de decisiones

Para decidir qué modelo de particionamiento SaaS multiusuario debe utilizar con PostgreSQL, consulte la siguiente matriz de decisiones. La matriz analiza estas cuatro opciones de particionamiento:

• Silo: una instancia o clúster de PostgreSQL independiente para cada inquilino.

• Puente con bases de datos independientes: una base de datos independiente para cada inquilino en una única instancia o clúster de PostgreSQL.

• Puente con esquemas separados: un esquema independiente para cada inquilino en una única base de datos de PostgreSQL, en una única instancia o clúster de PostgreSQL.

• Piscina: mesas compartidas para inquilinos en una sola instancia y esquema.

	Silo	Puente con bases de datos independientes	Puente con esquemas separados	piscina
Caso de uso	El aislamiento de los datos con un control total del uso de los recursos es un requisito clave, o tendrá inquilinos muy grandes y muy sensibles al rendimiento.	El aislamiento de los datos es un requisito clave y se requiere una referencia cruzada limitada o nula de los datos de los inquilinos.	Número moderado de inquilinos con una cantidad moderada de datos. Este es el modelo preferido si tiene que cruzar los datos de los inquilinos.	Gran cantidad de inquilinos con menos datos por inquilino.
Agilidad de incorporación de nuevos inquilinos	Muy lentos. (Se requiere una nueva instancia o clúster para cada inquilino).	Moderadamente lentos. (Requiere crear una nueva base de datos para que cada inquilino almacene los objetos del esquema).	Moderadamente lentos. (Requiere crear un nuevo esquema para que cada inquilino almacene los objetos).	La opción más rápida. (Se requiere una configuración mínima).
Esfuerzo y eficiencia de configuración del grupo de conexiones a bases de datos	Se requiere un esfuerzo significativo. (Un grupo de conexiones por inquilino). Menos eficiente. (No se comparten conexiones de bases de datos entre los inquilinos).	Se requiere un esfuerzo significativo. (Una configuración de grupo de conexiones por inquilino, a menos que utilice Amazon RDS Proxy). Menos eficiente. (No se comparten conexiones de bases de datos entre los inquilinos y el número total de conexiones. El uso para todos los inquilinos está limitado en función de la clase de instancia de base de datos.)	Requiere menos esfuerzo. (Una configuración de grupo de conexiones para todos los inquilinos). Moderadamente eficiente. (Reutilización de la conexión mediante elSET SCHEMA comandoSET ROLE o únicamente en el modo de grupo de sesiones. SETlos comandos también bloquean la sesión cuando se utiliza Amazon RDS Proxy, pero se pueden eliminar los grupos de conexiones de los clientes y se pueden establecer conexiones directas para cada solicitud para mayor eficiencia).	Se requiere el mínimo esfuerzo. Lo más eficiente. (Un grupo de conexiones para todos los inquilinos y una reutilización eficiente de las conexiones para todos los inquilinos. Los límites de conexión a la base de datos se basan en la clase de instancia de base de datos.)
Mantenimiento de bases de datos (gestión de vacíos) y uso de recursos	Administración más sencilla.	Complejidad media. (Puede provocar un alto consumo de recursos, ya que después hay que iniciar un aspirador para cada base de datosvacuum_naptime, lo que lleva a un uso elevado de la CPU del lanzador de vacío automático. También puede haber una sobrecarga adicional asociada a la aspiración de las tablas del catálogo del sistema PostgreSQL para cada base de datos).	Tablas de catálogo de sistemas PostgreSQL de gran tamaño. (pg_catalogTamaño total en decenas de GB, según el número de inquilinos y los parientes. Es probable que se requieran modificaciones en los parámetros relacionados con la aspiración para controlar la hinchazón de la mesa).	Las tablas pueden ser grandes, según el número de inquilinos y los datos de cada inquilino. (Es probable que se requieran modificaciones en los parámetros relacionados con la aspiración para controlar la hinchazón de la mesa).
Esfuerzo de gestión de extensiones	Esfuerzo significativo (para cada base de datos en instancias separadas).	Esfuerzo significativo (en cada nivel de base de datos).	Esfuerzo mínimo (una vez en la base de datos común).	Esfuerzo mínimo (una vez en la base de datos común).
Cambiar el esfuerzo de despliegue	Esfuerzo significativo. (Connect a cada instancia por separado e implemente los cambios).	Esfuerzo significativo. (Connect a cada base de datos y esquema e implemente los cambios).	Esfuerzo moderado. (Connect a una base de datos común e implemente los cambios para cada esquema).	Esfuerzo mínimo. (Connect a una base de datos común e implemente los cambios).
Despliegue de cambios: alcance del impacto	Mínimo. (Inquilino único afectado).	Mínimo. (Inquilino único afectado).	Mínimo. (Inquilino único afectado).	Muy grande. (Todos los inquilinos afectados).
Gestión y esfuerzo del rendimiento de las consultas	Rendimiento de las consultas administrable.	Rendimiento de las consultas administrable.	Rendimiento de las consultas administrable.	Es probable que se requiera un esfuerzo significativo para mantener el rendimiento de las consultas. (Con el tiempo, es posible que las consultas se ejecuten más lentamente debido al aumento del tamaño de las tablas. Puede utilizar las particiones de tablas y la fragmentación de bases de datos para mantener el rendimiento.)
Impacto en los recursos entre inquilinos	Sin impacto. (No se comparten recursos entre los inquilinos).	Impacto moderado. (Los inquilinos comparten recursos comunes, como la CPU y la memoria de la instancia).	Impacto moderado. (Los inquilinos comparten recursos comunes, como la CPU y la memoria de la instancia).	Impacto fuerte. (Los inquilinos se afectan unos a otros en términos de recursos, conflictos de bloqueo, etc.)
Ajuste a nivel de inquilino (por ejemplo, creación de índices adicionales por inquilino o ajuste de parámetros de base de datos para un inquilino en particular)	posibles.	Algo posible. (Se pueden realizar cambios a nivel de esquema para cada inquilino, pero los parámetros de la base de datos son globales para todos los inquilinos).	Algo posible. (Se pueden realizar cambios a nivel de esquema para cada inquilino, pero los parámetros de la base de datos son globales para todos los inquilinos).	No es posible. (Todos los inquilinos comparten las mesas).
Reequilibrar los esfuerzos para los inquilinos sensibles al desempeño	Mínimo. (No es necesario reequilibrar. Amplíe los recursos de servidor y E/S para gestionar este escenario).	Moderado. (Utilice la replicación lógica opg_dump para exportar la base de datos, pero el tiempo de inactividad puede ser prolongado según el tamaño de los datos. Puede usar la función de base de datos transportable de Amazon RDS for PostgreSQL para copiar bases de datos entre instancias con mayor rapidez).	Moderado, pero probablemente implique un tiempo de inactividad prolongado. (Utilice la replicación lógica opg_dump para exportar el esquema, pero el tiempo de inactividad puede ser prolongado según el tamaño de los datos).	Significativo, porque todos los inquilinos comparten las mismas mesas. (La fragmentación de la base de datos requiere copiar todo a otra instancia y realizar un paso adicional para limpiar los datos de los inquilinos). Lo más probable es que requiera un cambio en la lógica de la aplicación.
Tiempo de base de datos para actualizaciones de la versión principal	Tiempo de inactividad estándar. (Depende del tamaño del catálogo del sistema PostgreSQL).	Probablemente un tiempo de inactividad más prolongado. (Según el tamaño del catálogo del sistema, el tiempo variará. (Las tablas del catálogo del sistema PostgreSQL también se duplican en todas las bases de datos)	Probablemente un tiempo de inactividad más prolongado. (Según el tamaño del catálogo del sistema PostgreSQL, el tiempo variará).	Tiempo de inactividad estándar. (Depende del tamaño del catálogo del sistema PostgreSQL).
Sobrecarga de administración (por ejemplo, para el análisis de registros de bases de datos o la supervisión de trabajos de respaldo)	esfuerzo significativo	Esfuerzo mínimo.	Esfuerzo mínimo.	Esfuerzo mínimo.
Disponibilidad a nivel de inquilino	El más alto. (Cada inquilino fracasa y se recupera de forma independiente).	Mayor alcance de impacto. (Todos los inquilinos fallan y se recuperan juntos en caso de problemas de hardware o recursos).	Mayor alcance de impacto. (Todos los inquilinos fallan y se recuperan juntos en caso de problemas de hardware o recursos).	Mayor alcance de impacto. (Todos los inquilinos fallan y se recuperan juntos en caso de problemas de hardware o recursos).
Esfuerzo de respaldo y recuperación a nivel de inquilino	Menor esfuerzo. (Se puede realizar la copia de seguridad y de cada inquilino de seguridad.)	Esfuerzo moderado. (Utilice la exportación e importación lógicas para cada inquilino. Se requiere algo de codificación y automatización).	Esfuerzo moderado. (Utilice la exportación e importación lógicas para cada inquilino. Se requiere algo de codificación y automatización).	Esfuerzo significativo. (Todos los inquilinos comparten las mismas mesas).
Esfuerzo de point-in-time recuperación a nivel de inquilino	Esfuerzo mínimo. (Utilice la recuperación puntual mediante instantáneas o utilice el retroceso en Amazon Aurora).	Esfuerzo moderado. (Utilice la restauración de instantáneas, seguida de la exportación/importación. Sin embargo, será una operación lenta.)	Esfuerzo moderado. (Utilice la restauración de instantáneas, seguida de la exportación/importación. Sin embargo, será una operación lenta.)	Esfuerzo y complejidad significativos.
Nombre de esquema uniforme	El mismo nombre de esquema para cada inquilino.	El mismo nombre de esquema para cada inquilino.	Esquema diferente para cada inquilino.	Esquema común.
Personalización por inquilino (por ejemplo, columnas de tabla adicionales para un inquilino específico)	posibles.	posibles.	posibles.	Complicado (porque todos los inquilinos comparten las mismas mesas).
Eficiencia de la administración de catálogos en la capa de mapeo relacional de objetos (ORM) (por ejemplo, Ruby)	Eficiente (porque la conexión con el cliente es específica para un inquilino).	Eficiente (porque la conexión del cliente es específica de una base de datos).	Moderadamente eficiente. (Según el ORM utilizado, el modelo de seguridad del usuario y el rol y lasearch_path configuración, el cliente a veces almacena en caché los metadatos de todos los inquilinos, lo que provoca un uso elevado de la memoria de la conexión a la base de datos).	Eficiente (porque todos los inquilinos comparten las mismas mesas).
Esfuerzo de presentación de informes consolidados	Esfuerzo significativo. (Debe utilizar contenedores de datos extranjeros [FDW] para consolidar los datos de todos los inquilinos o extraer, transformar y cargar [ETL] en otra base de datos de informes).	Esfuerzo significativo. (Debe utilizar los FDW para consolidar los datos de todos los inquilinos o ETL en otra base de datos de informes).	Esfuerzo moderado. (Puede agregar datos en todos los esquemas mediante uniones).	Esfuerzo mínimo. (Todos los datos de los inquilinos están en las mismas tablas, por lo que los informes son sencillos).
Instancia de solo lectura específica del inquilino para la presentación de informes (por ejemplo, en función de la suscripción)	Menor esfuerzo. (Cree una réplica de lectura).	Esfuerzo moderado. (Puede usar la replicación lógica o elAWS Database Migration Service [AWS DMS] para configurar).	Esfuerzo moderado. (Puede usar la replicación lógica oAWS DMS para configurar).	Complicado (porque todos los inquilinos comparten las mismas mesas).
Aislamiento de datos	Lo mejor.	Mejor. (Puede administrar los permisos a nivel de base de datos mediante los roles de PostgreSQL).	Mejor. (Puede administrar los permisos a nivel de esquema mediante los roles de PostgreSQL).	Peor. (Como todos los inquilinos comparten las mismas tablas, hay que implementar funciones como la seguridad a nivel de fila [RLS] para aislar a los inquilinos).
Clave de cifrado de almacenamiento específica del inquilino	posibles. (Cada clúster de PostgreSQL puede tener su propia claveAWS Key Management Service [AWS KMS] para el cifrado del almacenamiento).	No es posible. (Todos los inquilinos comparten la misma clave KMS para el cifrado del almacenamiento).	No es posible. (Todos los inquilinos comparten la misma clave KMS para el cifrado del almacenamiento).	No es posible. (Todos los inquilinos comparten la misma clave KMS para el cifrado del almacenamiento).
Uso deAWS Identity and Access Management (IAM) para la autenticación de bases de datos para cada inquilino	posibles.	posibles.	Posible (al tener usuarios de PostgreSQL separados para cada esquema).	No es posible (porque las mesas las comparten todos los inquilinos).
costo de infraestructura	El más alto (porque no se comparte nada).	Moderado.	Moderado.	Más baja.
Duplicación de datos y uso del almacenamiento	El agregado más alto de todos los inquilinos. (Las tablas del catálogo del sistema PostgreSQL y los datos estáticos y comunes de la aplicación se duplican en todos los inquilinos).	El agregado más alto de todos los inquilinos. (Las tablas del catálogo del sistema PostgreSQL y los datos estáticos y comunes de la aplicación se duplican en todos los inquilinos).	Moderado. (Los datos estáticos y comunes de la aplicación pueden estar en un esquema común y otros inquilinos pueden acceder a ellos).	Mínimo. (Sin duplicación de datos. Los datos estáticos y comunes de la aplicación pueden estar en el mismo esquema).
Monitoreo centrado en el inquilino (averigüe rápidamente qué inquilino está causando problemas)	Menor esfuerzo. (Como cada inquilino es monitoreado por separado, es fácil comprobar la actividad de un inquilino específico).	Esfuerzo moderado. (Como todos los inquilinos comparten el mismo recurso físico, hay que aplicar filtros adicionales para comprobar la actividad de un inquilino específico).	Esfuerzo moderado. (Como todos los inquilinos comparten el mismo recurso físico, hay que aplicar filtros adicionales para comprobar la actividad de un inquilino específico).	Esfuerzo significativo. (Como todos los inquilinos comparten todos los recursos, incluidas las tablas, debe utilizar la captura de variables de enlace para comprobar a qué inquilino pertenece una consulta SQL específica).
Gestión centralizada y supervisión de la salud y la actividad	Esfuerzo significativo (para establecer un monitoreo central y un centro de comando central).	Esfuerzo moderado (porque todos los inquilinos comparten la misma instancia).	Esfuerzo moderado (porque todos los inquilinos comparten la misma instancia).	Esfuerzo mínimo (porque todos los inquilinos comparten los mismos recursos, incluido el esquema).
Posibilidades de que el identificador de objeto (OID) y el ID de la transacción (XID) coincidan	Mínimo.	Alta. (Debido a que OID, XID es un contador único para todo el clúster de PostgreSQL y puede haber problemas al pasar la aspiradora de forma eficaz en las bases de datos físicas).	Moderado. (Porque OID, XID es un contador único para todo el clúster de PostgreSQL).	Alta. (Por ejemplo, una sola tabla puede alcanzar el límite de 4 mil millones de TOAST OID, según el número de out-of-line columnas).