Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Modelos de particionamiento SaaS multiusuario para PostgreSQL


El mejor método para lograr la multitenencia depende de los requisitos de su aplicación SaaS. En las siguientes secciones se muestran los modelos de particionamiento para implementar correctamente la multitenencia en PostgreSQL. 

**nota**  
Los modelos descritos en esta sección son aplicables tanto a Amazon RDS for PostgreSQL como a los compatibles con Aurora PostgreSQL. Las referencias a *PostgreSQL* en esta sección se aplican a ambos servicios.

Hay tres modelos de alto nivel que puede utilizar en PostgreSQL para la partición de SaaS: silo, bridge y pool. La siguiente imagen resume las ventajas y desventajas entre los modelos de silo y de piscina. El modelo de puente es un híbrido de los modelos de silo y piscina.


****  

| **Modelo de particionamiento** | **Ventajas** | **Desventajas** | 
| --- | --- | --- | 
| Silo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 
| Grupo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 
| ¿Puente | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 

En las siguientes secciones se analiza cada modelo con más detalle.

**Topics**
+ [

# Modelo de silo PostgreSQL
](silo.md)
+ [

# Modelo de pool de PostgreSQL
](pool.md)
+ [

# Modelo de puente PostgreSQL
](bridge.md)
+ [

# Matriz de decisiones
](matrix.md)

# Modelo de silo PostgreSQL


El modelo de silo se implementa mediante el aprovisionamiento de una instancia de PostgreSQL para cada inquilino de una aplicación. *El modelo de silo destaca por el rendimiento de los inquilinos y el aislamiento de seguridad, y elimina por completo el fenómeno de los vecinos ruidosos.* El fenómeno del vecino ruidoso se produce cuando el uso de un sistema por parte de un inquilino afecta al rendimiento de otro inquilino. El modelo de silo le permite adaptar el rendimiento específicamente a cada inquilino y, potencialmente, limitar las interrupciones al silo de un inquilino específico. Sin embargo, lo que generalmente impulsa la adopción de un modelo de silos son las estrictas restricciones regulatorias y de seguridad. Estas limitaciones pueden estar motivadas por los clientes de SaaS. Por ejemplo, los clientes de SaaS pueden exigir que sus datos estén aislados debido a restricciones internas, y los proveedores de SaaS pueden ofrecer este servicio por una tarifa adicional. 

 ![\[SaaS PostgreSQL silo model\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-silo.png) 

Si bien el modelo de silo puede ser necesario en algunos casos, tiene muchos inconvenientes. A menudo resulta difícil utilizar el modelo de silo de forma rentable, ya que gestionar el consumo de recursos en varias instancias de PostgreSQL puede resultar complicado. Además, la naturaleza distribuida de las cargas de trabajo de las bases de datos de este modelo hace que sea más difícil mantener una visión centralizada de la actividad de los inquilinos. La administración de tantas cargas de trabajo operadas de forma independiente aumenta la sobrecarga operativa y administrativa. El modelo de silos también hace que la incorporación de inquilinos sea más complicada y lleve más tiempo, ya que hay que aprovisionar recursos específicos para cada inquilino. Además, todo el sistema SaaS puede resultar más difícil de escalar, ya que el número cada vez mayor de instancias de PostgreSQL específicas para cada inquilino exigirá más tiempo operativo para su administración. Una última consideración es que una aplicación o una capa de acceso a datos deberán mantener un mapeo de los inquilinos con sus instancias de PostgreSQL asociadas, lo que aumenta la complejidad de implementar este modelo.

# Modelo de pool de PostgreSQL


El modelo de grupo se implementa mediante el aprovisionamiento de una única instancia de PostgreSQL (Amazon RDS o Aurora) [y el uso de seguridad a nivel de fila (RLS) para mantener el aislamiento](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/) de los datos de los inquilinos. Las políticas de RLS restringen las filas de una tabla que devuelven las `SELECT` consultas o las filas que se ven afectadas por, y los comandos. `INSERT` `UPDATE` `DELETE` El modelo de agrupamiento centraliza todos los datos de los inquilinos en un único esquema PostgreSQL, por lo que resulta considerablemente más rentable y su mantenimiento requiere menos gastos operativos. La supervisión de esta solución también es considerablemente más sencilla debido a su centralización. Sin embargo, monitorear los impactos específicos de los inquilinos en el modelo de piscina generalmente requiere algunos instrumentos adicionales en la aplicación. Esto se debe a que, de forma predeterminada, PostgreSQL no sabe qué inquilino consume los recursos. La incorporación de inquilinos se simplifica porque no se requiere una nueva infraestructura. Esta agilidad facilita la creación de flujos de trabajo de incorporación de inquilinos rápidos y automatizados.

 ![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png) 

Si bien el modelo de grupo suele ser más rentable y sencillo de administrar, presenta algunas desventajas. El fenómeno de los vecinos ruidosos no se puede eliminar por completo en un modelo de piscina. Sin embargo, se puede mitigar asegurándose de que haya los recursos adecuados disponibles en la instancia de PostgreSQL y utilizando estrategias para reducir la carga en PostgreSQL, como transferir las consultas para leer réplicas o a Amazon. ElastiCache Una supervisión eficaz también contribuye a responder a los problemas de aislamiento del rendimiento de los inquilinos, ya que la instrumentación de las aplicaciones puede registrar y supervisar las actividades específicas de los inquilinos. Por último, es posible que algunos clientes de SaaS no consideren suficiente la separación lógica proporcionada por RLS y que soliciten medidas de aislamiento adicionales.

# Modelo de puente PostgreSQL


El modelo de puente PostgreSQL es una combinación de enfoques agrupados y aislados. Al igual que en el modelo agrupado, se aprovisiona una única instancia de PostgreSQL para cada inquilino. Para mantener el aislamiento de los datos de los inquilinos, se utilizan estructuras lógicas de PostgreSQL. En el siguiente diagrama, las bases de datos PostgreSQL se utilizan para separar los datos de forma lógica.

**nota**  
Una base de datos PostgreSQL no hace referencia a una instancia de base de datos independiente compatible con Amazon RDS for PostgreSQL o Aurora PostgreSQL. En cambio, se refiere a una construcción lógica del sistema de administración de bases de datos PostgreSQL para separar los datos.

 ![\[SaaS PostgreSQL bridge model with separate databases\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-dbs.png) 

También puede implementar el modelo puente mediante una única base de datos PostgreSQL, con esquemas específicos del inquilino en cada base de datos, como se muestra en el siguiente diagrama.

 ![\[SaaS PostgreSQL bridge model with separate schemas\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-schemas.png) 

El modelo de puente presenta los mismos problemas de aislamiento del rendimiento de vecinos y inquilinos ruidosos que el modelo de grupo. También supone una sobrecarga operativa y de aprovisionamiento adicional, ya que requiere el aprovisionamiento de bases de datos o esquemas independientes para cada inquilino. Requiere una supervisión eficaz para responder rápidamente a las inquietudes sobre el desempeño de los inquilinos. También requiere instrumentación de aplicación para monitorear el uso específico de los inquilinos. En general, el modelo puente puede considerarse una alternativa al RLS que aumenta ligeramente el esfuerzo de incorporación de los inquilinos al requerir nuevos esquemas o bases de datos de PostgreSQL. Al igual que con el modelo de silo, una aplicación o una capa de acceso a datos deberán mantener un mapeo de los inquilinos con sus bases de datos o esquemas de PostgreSQL asociados.

# Matriz de decisiones


Para decidir qué modelo de particionamiento de 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 diferente para cada inquilino en una única base de datos de PostgreSQL, en una sola instancia o clúster de PostgreSQL.
+ Pool: tablas compartidas para los inquilinos en una sola instancia y esquema.


****  

| **** | **Silo** | **Puente con bases de datos independientes** | **Puente con esquemas separados** | **Grupo** | 
| --- | --- | --- | --- | --- | 
| Caso de uso | El aislamiento de los datos con un control total del uso de los recursos es un requisito clave, o se trata de arrendatarios 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 hacer una referencia cruzada de los datos de los inquilinos. | Gran cantidad de inquilinos con menos datos por inquilino. | 
| Agilidad de incorporación de nuevos inquilinos | Muy lento. (Se requiere una nueva instancia o clúster para cada inquilino). | Moderadamente lento. (Requiere crear una nueva base de datos para cada inquilino a fin de almacenar los objetos del esquema). | Moderadamente lento. (Requiere crear un esquema nuevo para que cada inquilino almacene los objetos). | La opción más rápida. (Se requiere una configuración mínima). | 
| Esfuerzo y eficiencia en la configuración del conjunto de conexiones de bases de | Se requiere un esfuerzo significativo. (Un grupo de conexiones por inquilino). Menos eficiente. (No se comparte la conexión a la base 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html)).  Menos eficiente. (No hay conexión de base de datos compartida entre los inquilinos y el número total de conexiones. El uso en 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. (La conexión se reutiliza mediante el `SET SCHEMA` comando `SET ROLE` o únicamente en el modo de grupo de sesiones. `SET`los comandos también provocan el bloqueo de la sesión cuando se utiliza el proxy de Amazon RDS, pero se pueden eliminar los grupos de conexiones de los clientes y se pueden establecer conexiones directas para cada solicitud de eficiencia.) | Requiere el mínimo esfuerzo. El más eficiente. (Un grupo de conexiones para todos los inquilinos y una reutilización eficiente de las conexiones entre 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 la base de datos ([gestión del vacío](https://www.postgresql.org/docs/current/routine-vacuuming.html)) y uso de recursos | Administración más sencilla. | Complejidad media. (Puede conllevar un consumo elevado de recursos, ya que después hay que iniciar una máquina aspiradora para cada base de datosvacuum\$1naptime, lo que conlleva un uso elevado de la CPU del lanzador de aspiradoras automáticas. También puede haber una sobrecarga adicional asociada con la limpieza de las tablas del catálogo del sistema PostgreSQL para cada base de datos.) | Tablas de catálogo del sistema PostgreSQL de gran tamaño. (El pg\$1catalog tamaño total se expresa en decenas de GBs, según el número de inquilinos y las relaciones. Es probable que sea necesario modificar los parámetros relacionados con la aspiración para controlar la hinchazón de la mesa.) | Las tablas pueden ser grandes, en función del número de inquilinos y de los datos por inquilino. (Es probable que sea necesario modificar 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). | 
| Cambie el esfuerzo de implementación | Esfuerzo significativo. (Conéctese a cada instancia independiente e implemente los cambios). | Esfuerzo significativo. (Conéctese a cada base de datos y esquema e implemente los cambios). | Esfuerzo moderado. (Conéctese a una base de datos común e implemente los cambios para cada esquema). | Esfuerzo mínimo. (Conéctese a una base de datos común e implemente los cambios). | 
| Cambiar la implementación: alcance del impacto | Mínimo. (Inquilino único afectado). | Mínimo. (Inquilino único afectado). | Mínimo. (Inquilino único afectado). | Muy grande. (Todos los inquilinos están afectados). | 
| Consulta el rendimiento, la gestión y el esfuerzo | Rendimiento de consultas manejable. | Rendimiento de consultas manejable. | Rendimiento de consultas manejable. | Probablemente 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 la partición 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 los 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 entre sí 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) | Posible. | Algo posible. (Se pueden realizar cambios a nivel de esquema para cada arrendatario, pero los parámetros de la base de datos son globales en todos los arrendatarios). | Es algo posible. (Se pueden realizar cambios a nivel de esquema para cada arrendatario, pero los parámetros de la base de datos son globales en todos los arrendatarios). | No es posible. (Todos los inquilinos comparten las mesas). | 
| Reequilibre el esfuerzo para los inquilinos que se preocupan por su desempeño | Mínimo. (No es necesario volver a equilibrarlo. Amplíe el servidor y I/O los recursos para gestionar este escenario). | Moderado. (Utilice la replicación lógica o pg\$1dump exporte la base de datos, pero el tiempo de inactividad puede ser prolongado según el tamaño de los datos. Puede utilizar 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 o pg\$1dump exporte el esquema, pero el tiempo de inactividad puede ser prolongado según el tamaño de los datos). | Es importante, ya que todos los inquilinos comparten las mismas tablas. (La fragmentación de la base de datos requiere copiar todo en 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 inactividad de la base de datos para actualizaciones de versiones principales | Tiempo de inactividad estándar. (Depende del tamaño del catálogo del sistema PostgreSQL). | Es probable que haya más tiempo de inactividad. (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) | Es probable que haya más tiempo de inactividad. (Dependiendo del 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). | 
| Gastos generales de administración (por ejemplo, para el análisis de registros de bases de datos o la supervisión de tareas de respaldo) | Esfuerzo significativo | Esfuerzo mínimo. | Esfuerzo mínimo. | Esfuerzo mínimo. | 
| Disponibilidad a nivel de inquilino | La más alta. (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 | Esfuerzo mínimo. (Se puede hacer una copia de seguridad y restaurar a cada inquilino de forma independiente). | Esfuerzo moderado. (Utilice la exportación e importación lógicas para cada inquilino. Se requieren algunos procesos de codificación y automatización.) | Esfuerzo moderado. (Utilice la exportación e importación lógicas para cada inquilino. Se requieren algunos procesos de codificación y automatización.) | Esfuerzo significativo. (Todos los inquilinos comparten las mismas mesas). | 
| Esfuerzo de recuperación a nivel de inquilino point-in-time | 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 uniforme del esquema | 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) | Posible. | Posible. | Posible. | Complicado (porque todos los inquilinos comparten las mismas mesas). | 
| Eficiencia de la administración del catálogo 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 user/role seguridad y la search\$1path 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 tablas). | 
| Esfuerzo consolidado de informes sobre inquilinos | Esfuerzo significativo. (Debe utilizar contenedores de datos externos [FDWs] para consolidar los datos de todos los arrendatarios o extraer, transformar y cargar [ETL] en otra base de datos de informes). | Esfuerzo significativo. (Debe utilizarse FDWs para consolidar los datos de todos los inquilinos o de 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 la elaboración de informes es sencilla). | 
| Instancia de solo lectura específica para el inquilino para la elaboración de informes (por ejemplo, basada en una suscripción) | Esfuerzo mínimo. (Cree una réplica de lectura). | Esfuerzo moderado. (Puede usar la replicación lógica o AWS Database Migration Service [AWS DMS] para configurarlo). | Esfuerzo moderado. (Puede utilizar la replicación lógica o AWS DMS configurar). | Complicado (porque todos los inquilinos comparten las mismas tablas). | 
| Aislamiento de datos | Mejor. | Mejor. (Puede administrar los permisos a nivel de base de datos mediante funciones de PostgreSQL). | Mejor. (Puede administrar los permisos a nivel de esquema mediante roles de PostgreSQL). | Peor aún. (Como todos los inquilinos comparten las mismas tablas, debe implementar funciones como la seguridad a nivel de fila [RLS] para aislar a los inquilinos). | 
| Clave de cifrado de almacenamiento específica para cada inquilino | Posible. (Cada clúster de PostgreSQL puede tener su AWS Key Management Service propia clave 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 de AWS Identity and Access Management (IAM) para la autenticación de la base de datos de cada inquilino | Posible. | Posible. | Es posible (al tener usuarios de PostgreSQL separados para cada esquema). | No es posible (porque todos los inquilinos comparten las tablas). | 
| Coste de infraestructura | El más alto (porque no se comparte nada). | Moderado. | Moderado. | El más bajo. | 
| Duplicación de datos y uso del almacenamiento | El agregado más alto entre 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 entre 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. | 
| Supervisión centrada en el inquilino (averigüe rápidamente qué inquilino está causando los problemas) | Esfuerzo mínimo. (Como cada inquilino se monitorea 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, debe aplicar filtros adicionales para comprobar la actividad de un inquilino específico). | Esfuerzo moderado. (Como todos los inquilinos comparten el mismo recurso físico, debe 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). | 
| Administración y health/activity supervisión centralizadas | 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 transacción (XID) coincidan | Mínimas.  | Alta. (Gracias a OID, XID es un contador único para todo el clúster de PostgreSQL y puede haber problemas al pasar el aspirador de forma eficaz a todas las bases de datos físicas). | Moderado. (Como 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 OID de TOAST de 4 mil millones, según el número de columnas). out-of-line |