Por que o GaussDB(DWS) tem desempenho pior do que um banco de dados de servidor único em cenários extremes?

Devido à limitação da arquitetura MPP do GaussDB(DWS), alguns métodos e funções do PostgreSQL não podem ser enviados para DNs para execução. Como resultado, os gargalos de desempenho ocorrem em CNs.

Explicação:

• Uma operação só pode ser executada concorrentemente quando for logicamente uma operação concorrente. Por exemplo, SUM executada em todos os DNs simultaneamente deve centralizar o resumo final em um CN. Neste caso, a maior parte do trabalho de resumo foi concluída em DNs, de modo que o trabalho no CN é relativamente leve.
• Em alguns cenários, a operação deve ser executada centralmente em um nó. Por exemplo, atribuir um nome globalmente exclusivo a um ID de transação é implementado usando o sistema GTM. Portanto, o GTM também é um componente globalmente exclusivo (ativo/em espera). Todas as tarefas globalmente únicas são implementadas através do GTM em GaussDB(DWS), mas o código do software é otimizado para reduzir este tipo de tarefas. Portanto, o GTM não tem muitos gargalos. Em alguns cenários, GTM-Free e GTM-Lite podem ser implementados.
• Para garantir um excelente desempenho, os serviços precisam ser ligeiramente modificados para adaptação durante a migração do modo de desenvolvimento de aplicações do tradicional banco de dados de nó único para o banco de dados paralelo, especialmente para o tradicional aninhamento de procedimentos armazenados de Oracle.

Soluções:

• Se esse problema ocorrer, consulte "Otimização de desempenho de consulta" no Guia de desenvolvedor do Data Warehouse Service (DWS).
• Como alternativa, entre em contato com o suporte técnico para modificar e otimizar os serviços.