Upload
rodolphe-quiedeville
View
218
Download
1
Embed Size (px)
DESCRIPTION
Brown Bag Lunch sur inviation chez Novapost pour présenter les axes de réflexions pour la gestion de la montée en charge de PostgreSQL. Présentations de différents axes de travail afin d
Citation preview
PostgreSQL quatre ans après
Rodolphe Quiédeville
Novapost
21 mai 2014
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 1 / 43
Axes de travail10 axes de travail pour améliorer les performances et monter encharge en étant serein.
pgtunehardwaretablespacesreplicationconnection poolervaccummaterialized viewspartitionnementindexquery???
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 2 / 43
Axes de travail10 axes de travail pour améliorer les performances et monter encharge en étant serein.
pgtunehardwaretablespacesreplicationconnection poolervaccummaterialized viewspartitionnementindexquery???
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 2 / 43
Axes de travailpgtune
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 3 / 43
pgtune
Script d’optimisation des paramètres de postgresql.conf. L’étapenuméro une de toute optimisation.
utilisationpgtune -i /etc/postgresql/9.1/main/postgresql.conf
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 4 / 43
pgtune
Fait des propositions d’adaptation des paramètres de configuration aumatériel
Postulatpgtune considère qu’un seul cluster tourne sur la machine et quecelle-ci est dédiée au serveur de base de données
Restartcertains paramètres nécessite un redémarrage pour leur prise encompte
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 5 / 43
pgtune
Fait des propositions d’adaptation des paramètres de configuration aumatériel
Postulatpgtune considère qu’un seul cluster tourne sur la machine et quecelle-ci est dédiée au serveur de base de données
Restartcertains paramètres nécessite un redémarrage pour leur prise encompte
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 5 / 43
pgtune
Sortie du script
Example#custom_variable_classes = ’’ # list of custom variable class namesdefault_statistics_target = 50maintenance_work_mem = 176MBconstraint_exclusion = oncheckpoint_completion_target = 0.9effective_cache_size = 2GBwork_mem = 18MBwal_buffers = 8MBcheckpoint_segments = 16shared_buffers = 704MBmax_connections = 80
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 6 / 43
Axes de travailpgtunehardware
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 7 / 43
hardware
PostgreSQL a plusieurs flux de lecture/écriture, il faut en profiter tantque faire se peut.
plusieurs disquesplusieurs contrôlleursRAID10 au lieu de RAID5les WAL d’un coté les données de l’autre
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 8 / 43
hardware
PostgreSQL a plusieurs flux de lecture/écriture, il faut en profiter tantque faire se peut.
plusieurs disques
plusieurs contrôlleursRAID10 au lieu de RAID5les WAL d’un coté les données de l’autre
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 8 / 43
hardware
PostgreSQL a plusieurs flux de lecture/écriture, il faut en profiter tantque faire se peut.
plusieurs disquesplusieurs contrôlleurs
RAID10 au lieu de RAID5les WAL d’un coté les données de l’autre
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 8 / 43
hardware
PostgreSQL a plusieurs flux de lecture/écriture, il faut en profiter tantque faire se peut.
plusieurs disquesplusieurs contrôlleursRAID10 au lieu de RAID5
les WAL d’un coté les données de l’autre
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 8 / 43
hardware
PostgreSQL a plusieurs flux de lecture/écriture, il faut en profiter tantque faire se peut.
plusieurs disquesplusieurs contrôlleursRAID10 au lieu de RAID5les WAL d’un coté les données de l’autre
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 8 / 43
Axes de travailpgtunehardwaretablespaces
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 9 / 43
Tablespace
Les tablespaces permettent de définir l’emplacement dans le systèmede fichiers où seront stockés les fichiers représentant les objets de labase de données.
séparer les tables des indexséparer les tables d’archives des données fraicheslier les spécificités physique du stockage à l’utilisation logique desdonnées (session en SSD)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 10 / 43
Tablespace
Les tablespaces permettent de définir l’emplacement dans le systèmede fichiers où seront stockés les fichiers représentant les objets de labase de données.
séparer les tables des index
séparer les tables d’archives des données fraicheslier les spécificités physique du stockage à l’utilisation logique desdonnées (session en SSD)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 10 / 43
Tablespace
Les tablespaces permettent de définir l’emplacement dans le systèmede fichiers où seront stockés les fichiers représentant les objets de labase de données.
séparer les tables des indexséparer les tables d’archives des données fraiches
lier les spécificités physique du stockage à l’utilisation logique desdonnées (session en SSD)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 10 / 43
Tablespace
Les tablespaces permettent de définir l’emplacement dans le systèmede fichiers où seront stockés les fichiers représentant les objets de labase de données.
séparer les tables des indexséparer les tables d’archives des données fraicheslier les spécificités physique du stockage à l’utilisation logique desdonnées (session en SSD)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 10 / 43
Tablespace
CréationCREATE TABLESPACE espace_rapide LOCATION ’/mnt/sda1/postgresql/data’;
Création de la tableCREATE TABLE foo(i int) TABLESPACE espace1;
Le déplacement de données existantes est également possible.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 11 / 43
Axes de travailpgtunehardwaretablespacesreplication
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 12 / 43
replication
Vaste programme.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 13 / 43
replication
Vaste programme. La réplication est un des sujets les plus discutésdes bases de données à ce jour.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 14 / 43
replication
Vaste programme. La réplication est un des sujets les plus discutésdes bases de données à ce jour.
synchrone/asynchrone
warn/hot standbysingle/multi mastergranularité au niveau tableincore/middleware (pgpool-II)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 15 / 43
replication
Vaste programme. La réplication est un des sujets les plus discutésdes bases de données à ce jour.
synchrone/asynchronewarn/hot standby
single/multi mastergranularité au niveau tableincore/middleware (pgpool-II)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 15 / 43
replication
Vaste programme. La réplication est un des sujets les plus discutésdes bases de données à ce jour.
synchrone/asynchronewarn/hot standbysingle/multi master
granularité au niveau tableincore/middleware (pgpool-II)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 15 / 43
replication
Vaste programme. La réplication est un des sujets les plus discutésdes bases de données à ce jour.
synchrone/asynchronewarn/hot standbysingle/multi mastergranularité au niveau table
incore/middleware (pgpool-II)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 15 / 43
replication
Vaste programme. La réplication est un des sujets les plus discutésdes bases de données à ce jour.
synchrone/asynchronewarn/hot standbysingle/multi mastergranularité au niveau tableincore/middleware (pgpool-II)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 15 / 43
replication
Vaste programme. La réplication est un des sujets les plus discutésdes bases de données à ce jour.
synchrone/asynchronewarn/hot standbysingle/multi mastergranularité au niveau tableincore/middleware (pgpool-II)
WarningLa réplication est simple à mettre en oeuvre, la gérer au jour le jour estun travail de tous les jours.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 16 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection pooler
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 17 / 43
connection pooler
L’utilisation d’un pooler de connection est intéressant quand un grandnombre de connections sont créees pour de courtes durées. Unpooler peut aussi être intéressant conjointement avec une réplication.
pgbouncerpgpool-II
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 18 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection poolervaccum
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 19 / 43
vaccum
La commande VACUUM doit traiter chaque table régulièrement pourplusieurs raisons :
pour récupérer ou ré-utiliser l’espace disque occupé par les lignessupprimées ou mises à jourpour mettre à jour les statistiques utilisées par l’optimiseur dePostgreSQLpour mettre à jour la carte de visibilité qui accélère les parcoursd’index seulspour prévenir la perte des données les plus anciennes à caused’un cycle de l’identifiant de transaction (XID) ou d’un cycle del’identifiant de multixact.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 20 / 43
vaccum
La commande VACUUM doit traiter chaque table régulièrement pourplusieurs raisons :
pour récupérer ou ré-utiliser l’espace disque occupé par les lignessupprimées ou mises à jour
pour mettre à jour les statistiques utilisées par l’optimiseur dePostgreSQLpour mettre à jour la carte de visibilité qui accélère les parcoursd’index seulspour prévenir la perte des données les plus anciennes à caused’un cycle de l’identifiant de transaction (XID) ou d’un cycle del’identifiant de multixact.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 20 / 43
vaccum
La commande VACUUM doit traiter chaque table régulièrement pourplusieurs raisons :
pour récupérer ou ré-utiliser l’espace disque occupé par les lignessupprimées ou mises à jourpour mettre à jour les statistiques utilisées par l’optimiseur dePostgreSQL
pour mettre à jour la carte de visibilité qui accélère les parcoursd’index seulspour prévenir la perte des données les plus anciennes à caused’un cycle de l’identifiant de transaction (XID) ou d’un cycle del’identifiant de multixact.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 20 / 43
vaccum
La commande VACUUM doit traiter chaque table régulièrement pourplusieurs raisons :
pour récupérer ou ré-utiliser l’espace disque occupé par les lignessupprimées ou mises à jourpour mettre à jour les statistiques utilisées par l’optimiseur dePostgreSQLpour mettre à jour la carte de visibilité qui accélère les parcoursd’index seuls
pour prévenir la perte des données les plus anciennes à caused’un cycle de l’identifiant de transaction (XID) ou d’un cycle del’identifiant de multixact.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 20 / 43
vaccum
La commande VACUUM doit traiter chaque table régulièrement pourplusieurs raisons :
pour récupérer ou ré-utiliser l’espace disque occupé par les lignessupprimées ou mises à jourpour mettre à jour les statistiques utilisées par l’optimiseur dePostgreSQLpour mettre à jour la carte de visibilité qui accélère les parcoursd’index seulspour prévenir la perte des données les plus anciennes à caused’un cycle de l’identifiant de transaction (XID) ou d’un cycle del’identifiant de multixact.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 20 / 43
vaccumLa commande VACUUM doit traiter chaque table régulièrement pourplusieurs raisons :
pour récupérer ou ré-utiliser l’espace disque occupé par les lignessupprimées ou mises à jourpour mettre à jour les statistiques utilisées par l’optimiseur dePostgreSQLpour mettre à jour la carte de visibilité qui accélère les parcoursd’index seulspour prévenir la perte des données les plus anciennes à caused’un cycle de l’identifiant de transaction (XID) ou d’un cycle del’identifiant de multixact.
autovaccumSi vous ne savez pas à quoi sert autovaccum, laissez faireautovaccum.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 21 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection poolervaccummaterialized views
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 22 / 43
Vues matérialisées
Le meilleur de la table et de la vue.
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 23 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vuecrée une table physiqueporte ses propres indexscinde les flux de requêtesdoit être mise à jour suivant les besoins !le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vue
crée une table physiqueporte ses propres indexscinde les flux de requêtesdoit être mise à jour suivant les besoins !le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vuecrée une table physique
porte ses propres indexscinde les flux de requêtesdoit être mise à jour suivant les besoins !le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vuecrée une table physiqueporte ses propres index
scinde les flux de requêtesdoit être mise à jour suivant les besoins !le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vuecrée une table physiqueporte ses propres indexscinde les flux de requêtes
doit être mise à jour suivant les besoins !le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vuecrée une table physiqueporte ses propres indexscinde les flux de requêtesdoit être mise à jour suivant les besoins !
le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vuecrée une table physiqueporte ses propres indexscinde les flux de requêtesdoit être mise à jour suivant les besoins !le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
Le meilleur de la table et de la vue. Les meilleures alliées desbusiness analyst.
se crée comme une vuecrée une table physiqueporte ses propres indexscinde les flux de requêtesdoit être mise à jour suivant les besoins !le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en9.4)
New !A partir de PostgreSQL 9.3
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 24 / 43
Vues matérialisées
CréationCREATE MATERIALIZED VIEW resume_ventes AS
SELECTno_vendeur,date_facture,sum(mtt_facture)::numeric(13,2) as mtt_ventes
FROM factureWHERE date_facture < CURRENT_DATEGROUP BY
no_vendeur,date_facture
ORDER BYno_vendeur,date_facture;
CREATE UNIQUE INDEX ventes_resume_vendeurON sales_summary (no_vendeur, date_facture);
Mise à jourREFRESH MATERIALIZED VIEW resume_ventes;
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 25 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection poolervaccummaterialized viewspartitionnement
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 26 / 43
partitionnement
Le partitionnement fait référence à la division d’une table logiquevolumineuse en plusieurs parties physiques plus petites.
utilise l’héritage de tablepartitionnement par échelonpartitionnement par liste
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 27 / 43
partitionnement
Le partitionnement fait référence à la division d’une table logiquevolumineuse en plusieurs parties physiques plus petites.
utilise l’héritage de table
partitionnement par échelonpartitionnement par liste
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 27 / 43
partitionnement
Le partitionnement fait référence à la division d’une table logiquevolumineuse en plusieurs parties physiques plus petites.
utilise l’héritage de tablepartitionnement par échelon
partitionnement par liste
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 27 / 43
partitionnement
Le partitionnement fait référence à la division d’une table logiquevolumineuse en plusieurs parties physiques plus petites.
utilise l’héritage de tablepartitionnement par échelonpartitionnement par liste
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 27 / 43
partitionnement
Création table maître
SQLCREATE TABLE mesure (
id_ville int not null,date_trace date not null,temperature int,ventes int
);
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 28 / 43
partitionnement
Création des tables filles avec contraintes
SQLCREATE TABLE mesure_a2006m02 (
CHECK ( date_trace >= DATE ’2006-02-01’ AND date_trace < DATE’2006-03-01’ )
) INHERITS (mesure);
CREATE TABLE mesure_a2006m03 (CHECK ( date_trace >= DATE ’2006-03-01’ AND date_trace < DATE
’2006-04-01’ )) INHERITS (mesure);...
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 29 / 43
partitionnement
Création des index
SQLCREATE INDEX mesure_a2006m02_date_trace ON mesure_a2006m02 (date_trace);
CREATE INDEX mesure_a2006m03_date_trace ON mesure_a2006m03 (date_trace);...CREATE INDEX mesure_a2007m11_date_trace ON mesure_a2007m11 (date_trace);
CREATE INDEX mesure_a2007m12_date_trace ON mesure_a2007m12 (date_trace);
CREATE INDEX mesure_a2008m01_date_trace ON mesure_a2008m01 (date_trace);
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 30 / 43
partitionnement
Création des trigger
SQLCREATE OR REPLACE FUNCTION mesure_insert_trigger()RETURNS TRIGGER AS $$BEGIN
INSERT INTO mesure_a2008m01 VALUES (NEW.*);RETURN NULL;
END;$$LANGUAGE plpgsql;
SQLCREATE TRIGGER insert_mesure_trigger
BEFORE INSERT ON mesureFOR EACH ROW EXECUTE PROCEDURE mesure_insert_trigger();
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 31 / 43
partitionnement
Attention à l’utilisation
SQLrodo@[local]:5432 rodo=> explain select * from mesure ;
QUERY PLAN--------------------------------------------------------------------------Append (cost=0.00..55.40 rows=3541 width=16)
-> Seq Scan on mesure (cost=0.00..0.00 rows=1 width=16)-> Seq Scan on mesure_a2006m02 (cost=0.00..27.70 rows=1770 width=16)-> Seq Scan on mesure_a2006m03 (cost=0.00..27.70 rows=1770 width=16)
(4 rows)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 32 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection poolervaccummaterialized viewshéritage de tableindex
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 33 / 43
index
Il s’avère que la seule chose que les développeurs doiventconnaître est l’indexation. En fait, l’indexation d’une base dedonnées est un travail de développeurs car l’information laplus importante pour une bonne indexation ne se situe ni auniveau de la configuration du système de stockage ni dans laconfiguration du matériel, mais plutôt au niveau del’application :
« comment l’application cherche ses données ».
Markus Winand - http://use-the-index-luke.com/fr
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 34 / 43
index
Trop d’index nuit à la performance. Mettre à jour un index qui n’estjamais lu n’est pas forcément nécessaire.
SQLindexrelname | idx_scan | idx_tup_read | idx_tup_fetch
--------------------+----------+--------------+---------------job_job_fkposte_id | 0 | 0 | 0job_job_region_id | 0 | 0 | 0job_job_company_id | 43 | 323 | 305job_job_author_id | 0 | 0 | 0job_job_pkey | 22968 | 22930 | 22911
(5 rows)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 35 / 43
index
Trop d’index nuit à la performance. Mettre à jour un index qui n’estjamais lu n’est pas forcément nécessaire.
SQLindexrelname | idx_scan | idx_tup_read | idx_tup_fetch
--------------------+----------+--------------+---------------job_job_fkposte_id | 0 | 0 | 0job_job_region_id | 0 | 0 | 0job_job_company_id | 43 | 323 | 305job_job_author_id | 0 | 0 | 0job_job_pkey | 22968 | 22930 | 22911
(5 rows)
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 35 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection poolervaccummaterialized viewshéritage de tableindexquery
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 36 / 43
query
La ré-écriture des requêtes et le travail coté application
la requête la plus rapide est celle qui n’est pas éxecutéerien ne sert de ré-écrire les index si les requêtes ne les utilisentpascertains axes d’optimisation ne sont pas compatible avec lesframework mal conçus
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 37 / 43
query
La ré-écriture des requêtes et le travail coté application
la requête la plus rapide est celle qui n’est pas éxecutée
rien ne sert de ré-écrire les index si les requêtes ne les utilisentpascertains axes d’optimisation ne sont pas compatible avec lesframework mal conçus
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 37 / 43
query
La ré-écriture des requêtes et le travail coté application
la requête la plus rapide est celle qui n’est pas éxecutéerien ne sert de ré-écrire les index si les requêtes ne les utilisentpas
certains axes d’optimisation ne sont pas compatible avec lesframework mal conçus
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 37 / 43
query
La ré-écriture des requêtes et le travail coté application
la requête la plus rapide est celle qui n’est pas éxecutéerien ne sert de ré-écrire les index si les requêtes ne les utilisentpascertains axes d’optimisation ne sont pas compatible avec lesframework mal conçus
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 37 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection poolervaccummaterialized viewshéritage de tableindexquery???
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 38 / 43
Axes de travailpgtunehardwaretablespacesreplicationconnection poolervaccummaterialized viewshéritage de tableindexqueryschema
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 39 / 43
schema
Last but not least, le schema reste la source numéro un desproblèmes de performance et de montée en charge.
tableviewindex"les jointures c’est bon mangez-en"
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 40 / 43
schema
Last but not least, le schema reste la source numéro un desproblèmes de performance et de montée en charge.
table
viewindex"les jointures c’est bon mangez-en"
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 40 / 43
schema
Last but not least, le schema reste la source numéro un desproblèmes de performance et de montée en charge.
tableview
index"les jointures c’est bon mangez-en"
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 40 / 43
schema
Last but not least, le schema reste la source numéro un desproblèmes de performance et de montée en charge.
tableviewindex
"les jointures c’est bon mangez-en"
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 40 / 43
schema
Last but not least, le schema reste la source numéro un desproblèmes de performance et de montée en charge.
tableviewindex"les jointures c’est bon mangez-en"
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 40 / 43
Conclusion
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 41 / 43
Conclusion
Tout modification structurelle doit s’accompagner d’un processus devalidation itératif.
1 rédaction d’un protocole de test avec son jeu de données2 mesure des indicateurs3 modification d’un paramètre4 mesure des même indicateurs5 analyse des résultats6 goto 3 | 1
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 42 / 43
Conclusion
Tout modification structurelle doit s’accompagner d’un processus devalidation itératif.
1 rédaction d’un protocole de test avec son jeu de données
2 mesure des indicateurs3 modification d’un paramètre4 mesure des même indicateurs5 analyse des résultats6 goto 3 | 1
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 42 / 43
Conclusion
Tout modification structurelle doit s’accompagner d’un processus devalidation itératif.
1 rédaction d’un protocole de test avec son jeu de données2 mesure des indicateurs
3 modification d’un paramètre4 mesure des même indicateurs5 analyse des résultats6 goto 3 | 1
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 42 / 43
Conclusion
Tout modification structurelle doit s’accompagner d’un processus devalidation itératif.
1 rédaction d’un protocole de test avec son jeu de données2 mesure des indicateurs3 modification d’un paramètre
4 mesure des même indicateurs5 analyse des résultats6 goto 3 | 1
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 42 / 43
Conclusion
Tout modification structurelle doit s’accompagner d’un processus devalidation itératif.
1 rédaction d’un protocole de test avec son jeu de données2 mesure des indicateurs3 modification d’un paramètre4 mesure des même indicateurs
5 analyse des résultats6 goto 3 | 1
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 42 / 43
Conclusion
Tout modification structurelle doit s’accompagner d’un processus devalidation itératif.
1 rédaction d’un protocole de test avec son jeu de données2 mesure des indicateurs3 modification d’un paramètre4 mesure des même indicateurs5 analyse des résultats
6 goto 3 | 1
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 42 / 43
Conclusion
Tout modification structurelle doit s’accompagner d’un processus devalidation itératif.
1 rédaction d’un protocole de test avec son jeu de données2 mesure des indicateurs3 modification d’un paramètre4 mesure des même indicateurs5 analyse des résultats6 goto 3 | 1
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 42 / 43
Questions ?
Rodolphe Quiédeville
[email protected]://blog.rodolphe.quiedeville.org/
Document publié sous Licence Creative Commons BY-SA 2.0
Rodolphe Quiédeville (Freelance) PostgreSQL quatre ans après 21 mai 2014 43 / 43