web-dev-qa-db-fra.com

Cloudsql avec PostgreSQL très lente performance

Je voulais migrer de BigQuery vers Cloudsql pour économiser des coûts. Mon problème est que Cloudsql avec PostgreSQL est très très lent, comparez à BigQuery. Une requête qui prend 1,5 seconde dans la bigquery prend près de 4,5 minutes (!) Sur Cloudsql avec PostgreSQL.

J'ai CloudSQL avec PostgreSQL Server avec les configurations suivantes:

enter image description here

Ma base de données a une table principale avec des rangées de 16 m (environ 14 Go en RAM).

Un exemple de requête:

EXPLAIN ANALYZE 
  SELECT 
    "title"
  FROM 
    public.videos
  WHERE 
      EXISTS (SELECT 
                * 
              FROM (
                    SELECT 
                      COUNT(DISTINCT CASE WHEN LOWER(param) LIKE '%thriller%' THEN '0'
                                          WHEN LOWER(param) LIKE '%crime%' THEN '1' END) AS count
                    FROM
                      UNNEST(categories) AS param
                    ) alias
                        WHERE count = 2)

  ORDER BY views DESC 

  LIMIT 12 OFFSET 0

La table est une videos tables avec categories colonne comme text[]. L'état de recherche ici semble là où il y a une catégorie comme '%thriller%' et comme '%crime%' exactement deux fois

L'analyse expliquée de cette requête donne cette sortie (CSV): link . L'explique (tampons) de cette requête donne cette sortie (CSV): link .

Graphique des insignes de requête:

enter image description here

Profil de mémoire:

enter image description here

Référence BigQuery pour la même requête sur la même taille de table:

enter image description here

Configuration du serveur: link .

Tableau Décrivez: Link .

Mon objectif est d'avoir Cloud SQL avec la même vitesse de requête que la grosse requête

postgresqlquery-optimizationgoogle-cloud-sql
5
dasdasd

La requête initiale semble surchargée. Il pourrait être réécrit comme suit:

SELECT  v."title"
FROM public.videos v
WHERE array_to_string(v.categories, '^') ILIKE ALL (ARRAY['%thriller%', '%crime%'])
ORDER BY views DESC 
LIMIT 12 OFFSET 0;

DB <> Fiddle Demo

1
Lukasz Szozda

Pour tous ceux qui arrivent ici se demandent comment syntoniser leur machine Postgres sur Cloud SQL, ils appellent des drapeaux informatiques et vous pouvez le faire à partir de l'interface utilisateur, mais toutes les options de configuration ne sont pas modifiées.

https://cloud.google.com/sql/docs/postgres/flags#console

1
dasdasd

PostgreSQL est très lent par la conception sur chaque requête impliquant la fonction globale comptable et il n'ya absolument rien à faire à l'exception de la vue matérialisée pour appliquer les performances.

Les tests que j'ai faits sur ma machine avec 48 cœurs sur Compter les performances de PostgreSQL à MS SQL Server Effacer: SQL Server est compris entre 61 et 561 fois plus rapidement dans toutes les situations et avec le serveur SQL Columnstore Index SQL. Peut être 1 533 temps plus rapide ...

La même vitesse est atteinte lors de l'utilisation de tout autre SGBDM. L'explication est clairement le PG MVCC qui maintiennent des rangées fantômes à l'intérieur de la table et des pages d'index, qui doit parcourir toutes les lignes de savoir s'il s'agit d'une rangée active ou fantôme ... dans tous les autres RDBMS, le comte est fait en lisant un seul Informations En haut de la page (nombre de lignes de la page) et à l'aide d'un accès parallèle ou d'un serveur SQL, un accès par lots et non une ligne d'accès ...

Il n'y a rien à faire pour accélérer le nombre de comptes dans pg jusqu'à ce que le moteur de stockage ne réécrirea pas dans les pages de fantômes.

0
SQLpro

Outre l'optimisation SQL Syntaxe, avez-vous essayé de postgresql Tune?

Je vérifie que l'explication n'a trouvé que deux travailleurs en parallèle et 25 kmmemorie utilisée dans le tri.

Travailleurs planifiés: 2 "Méthode de tri: QuickSort Memory: 25kb"

Pour votre requête, il est typique OLAP Requête. Les performances de la mémoire et les cœurs de la mémoire utilisées (travailleurs). Les postgres par défaut utilisent la mémoire de niveau KB et peu de travailleurs. Vous pouvez accorder votre postgretsql.conf à optimiser son fonctionnement comme OLAP Type de base de données.

========================================================== = Voici ma suggestion: utilisez plus de mémoire (9 Mo comme travail de travail) et plus de CPU (max 16)

# DB Version: 13
# OS Type: linux
# DB Type: dw
# Total Memory (RAM): 24 GB
# CPUs num: 16
# Data Storage: ssd

max_connections = 40
shared_buffers = 6GB
effective_cache_size = 18GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 9830kB
min_wal_size = 4GB
max_wal_size = 16GB
max_worker_processes = 16
max_parallel_workers_per_gather = 8
max_parallel_workers = 16
max_parallel_maintenance_workers = 4

Vous pouvez l'ajouter à la dernière ligne PostgreSql.conf. Et redémarrez votre serveur PostgreSQL pour l'adapter.

À l'optimisation ultérieure,

  1. réduisez la connexion et augmentez le travail. 200 * 9830 est d'environ 2 Go de mémoire pour toutes les connexions. Si vous avez moins de connexions (par exemple, 100), vous pouvez obtenir plus de mémoire pour la requête.

========================================== Connaissance de l'utilisation du type de tableau de texte et inhormes. Vous pouvez essayer d'ajouter un index approprié.

C'est tout, bonne chance.

Wangyong

0
Yong Wang