ApsaraDB RDS:Recomendaciones de desarrollo y operaciones

Pool de conexiones

minimumIdle=1, maximumPoolSize=15, idleTimeout=600000 (10 minutes), maxLifetime=3600000 (60 minutes)

sqlDB.SetMaxIdleConns(1), sqlDB.SetMaxOpenConns(15), sqlDB.SetConnMaxLifetime(time.Hour)

initialSize=1, minIdle=1, maxIdle=1, maxActive=15, testOnBorrow=false, testOnReturn=false, testWhileIdle=true, minEvictableIdleTimeMillis=600000 (10 minutes), maxEvictableIdleTimeMillis=900000 (15 minutes), timeBetweenEvictionRunsMillis=60000 (1 minute), maxWait=6000 (6 seconds)

Rendimiento y estabilidad

• Una sola base de datos corresponde a una carpeta en el sistema de archivos subyacente. Las tablas, particiones e índices corresponden a archivos dentro de esa carpeta. Si la cantidad de archivos supera los 20 millones, la instancia reportará un error de espacio en disco agotado. Divida la base de datos o fusione los archivos de tabla según su carga de trabajo.

• Use CREATE INDEX CONCURRENTLY para crear índices en cargas de trabajo en línea. Esto evita bloquear las operaciones INSERT, UPDATE y DELETE sobre la tabla destino en otras sesiones.

• Para instancias con PostgreSQL 12 o posterior, use REINDEX CONCURRENTLY para reconstruir índices. En PostgreSQL 11 o anterior, utilice CREATE INDEX ... CONCURRENTLY para crear un índice de reemplazo y luego elimine el original.

• Evite crear y eliminar tablas temporales con frecuencia, pues esto incrementa la sobrecarga de las tablas del sistema. Tenga precaución con ON COMMIT DROP. En la mayoría de los casos, utilice una cláusula WITH en lugar de una tabla temporal.

• PostgreSQL 13 mejora la compatibilidad con tablas particionadas, las operaciones HashAggregate para cláusulas GROUP BY y las consultas paralelas. Actualice su instancia a PostgreSQL 13 siempre que sea posible. Para obtener más información, consulte Upgrade the major engine version of an ApsaraDB RDS for PostgreSQL instance.

• Deshabilite la función de cursor si ya no la utiliza.

• Utilice TRUNCATE en lugar de DELETE para eliminar datos a nivel de tabla, ya que TRUNCATE es significativamente más rápido.

• Envuelva las sentencias DDL en transacciones para poder revertirlas si es necesario. Mantenga las transacciones breves: las transacciones DDL largas bloquean las operaciones de lectura sobre los objetos que tienen bloqueados.

• Para escrituras masivas de datos, utilice COPY o INSERT INTO table VALUES (),(),...(); con múltiples filas para maximizar el throughput de escritura.

Versión menor del motor

• Para utilizar la función de slot de replicación, actualice la versión menor del motor a 20201230 o posterior. Esto habilita la función Logical Replication Slot Failover y permite configurar una regla de alerta para la métrica Maximum Replication Slot Latency, lo que evita que las suscripciones lógicas se retrasen o se interrumpan. Si las suscripciones lógicas se retrasan o interrumpen, se pierden los slots de replicación y se acumulan registros de write-ahead logging (WAL). Para obtener más información, consulte Logical Replication Slot Failover y Manage the alert rules of an ApsaraDB RDS for PostgreSQL instance.

• Para usar la función de registro de auditoría o la función Performance Insight, actualice la versión menor del motor a 20211031 o posterior.

  Cuando log_statement se establece en all , el rendimiento mejora aproximadamente cuatro veces en escenarios con más de 50 conexiones activas, y se evitan picos significativos en la utilización de CPU.

Monitoreo y alertas

• Active Initiative Alert para habilitar las reglas de alerta predeterminadas que proporciona la función de monitoreo y alertas. Para obtener más información, consulte Manage the alerts.

• Establezca el umbral de alerta de uso de memoria entre 85% y 95% según las características de su carga de trabajo.

Solución de problemas

Para identificar las sentencias SQL con mayor consumo de recursos (Top SQL), consulte Find the most resource-intensive SQL statements (Top SQL).

Para identificar las sentencias SQL con mayor consumo de recursos, consulte Locate SQL statements with the highest resource consumption.

Diseño

Consulta de datos

• Utilice COUNT(*) en lugar de COUNT(column_name) o COUNT(constants). COUNT(*) es el estándar SQL-92 para contar filas e incluye valores NULL. COUNT(column_name) excluye los valores NULL y produce un resultado diferente.

• Para COUNT(DISTINCT) en varias columnas, encierre la lista de columnas entre paréntesis:

  COUNT( (col1, col2, col3) )

  COUNT(DISTINCT) incluye todos los valores NULL, por lo que produce el mismo resultado que COUNT(*).

• Evite SELECT * FROM t. Especifique únicamente las columnas que necesita para evitar devolver datos innecesarios.

• Evite devolver conjuntos de resultados grandes a los clientes de base de datos, salvo en operaciones de extracción, transformación y carga (ETL). Si una consulta devuelve un conjunto de resultados anormalmente grande, compruebe si su plan de ejecución es óptimo.

• Para consultas por rango, utilice tipos de datos Range con índices GiST para mejorar el rendimiento.

• Si su aplicación ejecuta frecuentemente consultas que devuelven muchas filas, agrupe los resultados en lotes. Por ejemplo, si una consulta devuelve 100 filas, agréguelas en un solo conjunto de resultados. Si su aplicación accede a los resultados por ID, agréguelos periódicamente por ID. Los conjuntos de resultados más pequeños reducen el tiempo de respuesta.

Gestión de instancias

• Habilite la función SQL Explorer and Audit para consultar y exportar información sobre la ejecución de SQL, incluidas las bases de datos consultadas, el estado de ejecución y las duraciones. Utilice esta función para diagnosticar el estado del SQL, solucionar problemas de rendimiento y analizar el tráfico. Para obtener más información, consulte Use the SQL Explorer and Audit feature on an ApsaraDB RDS for PostgreSQL instance.

• Para monitorear y registrar la actividad dentro de su cuenta de Alibaba Cloud —incluyendo accesos desde la consola, API y herramientas de desarrollo— utilice ActionTrail. ActionTrail registra estas acciones como eventos que puede descargar desde la consola de ActionTrail o enviar a Logstores de Log Service o buckets de Object Storage Service (OSS) para análisis de seguridad, seguimiento de cambios en recursos o auditorías de cumplimiento. Para obtener más información, consulte What is ActionTrail?.

• Revise todas las operaciones DDL antes de ejecutarlas y programe los cambios DDL durante horas de baja demanda.

• Antes de confirmar transacciones que eliminen o modifiquen datos, ejecute una sentencia SELECT para confirmar las filas afectadas. Si su lógica de negocio requiere actualizar exactamente una fila, agregue LIMIT 1.

• Para operaciones DDL y otras operaciones que adquieren bloqueos —como VACUUM FULL y CREATE INDEX— establezca un tiempo de espera de bloqueo para evitar que bloqueen consultas indefinidamente:

  BEGIN;
  SET LOCAL lock_timeout = '10s';
  -- DDL statement;
  END;

• Utilice EXPLAIN ANALYZE para inspeccionar el plan de ejecución de una consulta. A diferencia de EXPLAIN, EXPLAIN ANALYZE ejecuta realmente la consulta. Si el plan involucra operaciones DML (UPDATE, INSERT o DELETE), envuelva la sentencia en una transacción y reviértala después de la inspección para evitar cambios no deseados en los datos:

  BEGIN;
  EXPLAIN (ANALYZE) <DML (UPDATE/INSERT/DELETE) SQL>;
  ROLLBACK;

• Para eliminaciones o actualizaciones a gran escala, procese los datos en lotes, cada uno en su propia transacción. Eliminar o actualizar todas las filas en una sola transacción genera grandes cantidades de datos obsoletos.