¿Por qué GaussDB(DWS) funciona peor que una base de datos de un solo servidor en los escenarios extremos?

Debido a la limitación de la arquitectura MPP de GaussDB(DWS), algunos métodos y funciones de PostgreSQL no se pueden enviar a los DN para su ejecución. Como resultado, se producen cuellos de botella de rendimiento en los CN.

Explicación:

• Una operación puede ejecutarse concurrentemente sólo cuando es lógicamente una operación concurrente. Por ejemplo, SUM realizada en todos los DN simultáneamente debe centralizar el resumen final en un CN. En este caso, la mayor parte del trabajo de resumen se ha completado en DN, por lo que el trabajo en el CN es relativamente ligero.
• En algunos escenarios, la operación debe ejecutarse centralmente en un nodo. Por ejemplo, la asignación de un nombre global único a un ID de transacción se implementa usando el sistema GTM. Por lo tanto, el GTM es también un componente único a nivel mundial (activo/en espera). Todas las tareas únicas a nivel mundial se implementan a través del GTM en GaussDB(DWS), pero el código de software está optimizado para reducir este tipo de tareas. Por lo tanto, el GTM no tiene muchos cuellos de botella. En algunos escenarios, GTM-Free y GTM-Lite pueden ser implementados.
• Para garantizar un excelente rendimiento, los servicios deben modificarse ligeramente para su adaptación durante la migración desde el modo de desarrollo de aplicaciones de la base de datos tradicional de un solo nodo al de la base de datos paralela, especialmente para el anidamiento de procedimientos almacenados tradicionales de Oracle.

Soluciones:

• Si se produce un problema de este tipo, consulte "Optimización del rendimiento de consultas" en la Guía para desarrolladores de Data Warehouse Service (DWS).
• Alternativamente, póngase en contacto con el soporte técnico para modificar y optimizar los servicios.