BBL autour de PostgreSQL @Novapost

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 travail
10 axes de travail pour améliorer les performances et monter en
charge en étant serein.

Axes de travail
10 axes de travail pour améliorer les performances et monter en
charge en étant serein.
pgtune
hardware
tablespaces
replication
connection pooler
vaccum
materialized views
partitionnement
index
query
???

Axes de travail
pgtune

pgtune
Script d’optimisation des paramètres de postgresql.conf. L’étape
numéro une de toute optimisation.
utilisation
pgtune -i /etc/postgresql/9.1/main/postgresql.conf

pgtune
Fait des propositions d’adaptation des paramètres de conﬁguration au
matériel
Postulat
pgtune considère qu’un seul cluster tourne sur la machine et que
celle-ci est dédiée au serveur de base de données

pgtune
Fait des propositions d’adaptation des paramètres de conﬁguration au
matériel
Postulat
pgtune considère qu’un seul cluster tourne sur la machine et que
celle-ci est dédiée au serveur de base de données
Restart
certains paramètres nécessite un redémarrage pour leur prise en
compte

pgtune
Sortie du script
Example
#custom_variable_classes = ’’ # list of custom variable class names
default_statistics_target = 50
maintenance_work_mem = 176MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 2GB
work_mem = 18MB
wal_buffers = 8MB
checkpoint_segments = 16
shared_buffers = 704MB
max_connections = 80

Axes de travail
pgtune
hardware

hardware
PostgreSQL a plusieurs ﬂux de lecture/écriture, il faut en proﬁter tant
que faire se peut.

hardware
que faire se peut.
plusieurs disques

hardware
que faire se peut.
plusieurs disques
plusieurs contrôlleurs

hardware
que faire se peut.
plusieurs disques
RAID10 au lieu de RAID5

hardware
que faire se peut.
plusieurs disques
RAID10 au lieu de RAID5
les WAL d’un coté les données de l’autre

Axes de travail
pgtune
hardware
tablespaces

Tablespace
Les tablespaces permettent de définir l’emplacement dans le système
de fichiers où seront stockés les fichiers représentant les objets de la
base de données.

Tablespace
base de données.
séparer les tables des index

Tablespace
base de données.
séparer les tables d’archives des données fraiches

Tablespace
base de données.
séparer les tables d’archives des données fraiches
lier les spéciﬁcités physique du stockage à l’utilisation logique des
données (session en SSD)

Tablespace
Création
CREATE TABLESPACE espace_rapide LOCATION ’/mnt/sda1/postgresql/data’;
Création de la table
CREATE TABLE foo(i int) TABLESPACE espace1;
Le déplacement de données existantes est également possible.

Axes de travail
pgtune
hardware
tablespaces
replication

replication
Vaste programme.

replication
Vaste programme. La réplication est un des sujets les plus discutés
des bases de données à ce jour.

replication
synchrone/asynchrone

replication
warn/hot standby

replication
warn/hot standby
single/multi master

replication
warn/hot standby
single/multi master
granularité au niveau table

replication
warn/hot standby
single/multi master
incore/middleware (pgpool-II)

replication
warn/hot standby
single/multi master
incore/middleware (pgpool-II)
Warning
La réplication est simple à mettre en oeuvre, la gérer au jour le jour est
un travail de tous les jours.

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler

connection pooler
L’utilisation d’un pooler de connection est intéressant quand un grand
nombre de connections sont créees pour de courtes durées. Un
pooler peut aussi être intéressant conjointement avec une réplication.
pgbouncer
pgpool-II

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler
vaccum

vaccum
La commande VACUUM doit traiter chaque table régulièrement pour
plusieurs raisons :

vaccum
plusieurs raisons :
pour récupérer ou ré-utiliser l’espace disque occupé par les lignes
supprimées ou mises à jour

vaccum
plusieurs raisons :
pour mettre à jour les statistiques utilisées par l’optimiseur de
PostgreSQL

vaccum
plusieurs raisons :
PostgreSQL
pour mettre à jour la carte de visibilité qui accélère les parcours
d’index seuls

vaccum
plusieurs raisons :
PostgreSQL
d’index seuls
pour prévenir la perte des données les plus anciennes à cause
d’un cycle de l’identiﬁant de transaction (XID) ou d’un cycle de
l’identiﬁant de multixact.

vaccum
plusieurs raisons :
PostgreSQL
d’index seuls
pour prévenir la perte des données les plus anciennes à cause
d’un cycle de l’identiﬁant de transaction (XID) ou d’un cycle de
l’identiﬁant de multixact.
autovaccum
Si vous ne savez pas à quoi sert autovaccum, laissez faire
autovaccum.

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler
vaccum
materialized views

Vues matérialisées
Le meilleur de la table et de la vue.

Le meilleur de la table et de la vue. Les meilleures alliées des
business analyst.

business analyst.
se crée comme une vue

business analyst.
crée une table physique

business analyst.
porte ses propres index

business analyst.
scinde les ﬂux de requêtes

business analyst.
doit être mise à jour suivant les besoins !

business analyst.
le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en
9.4)

business analyst.
le REFRESH prend un ACCESS EXCLUSIVE LOCK (corrigé en
9.4)
New !
A partir de PostgreSQL 9.3

Création
CREATE MATERIALIZED VIEW resume_ventes AS
SELECT
no_vendeur,
date_facture,
sum(mtt_facture)::numeric(13,2) as mtt_ventes
FROM facture
WHERE date_facture < CURRENT_DATE
GROUP BY
no_vendeur,
date_facture
ORDER BY
no_vendeur,
date_facture;
CREATE UNIQUE INDEX ventes_resume_vendeur
ON sales_summary (no_vendeur, date_facture);
Mise à jour
REFRESH MATERIALIZED VIEW resume_ventes;

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler
vaccum
materialized views
partitionnement

partitionnement
Le partitionnement fait référence à la division d’une table logique
volumineuse en plusieurs parties physiques plus petites.

partitionnement
utilise l’héritage de table

partitionnement
partitionnement par échelon

partitionnement
partitionnement par échelon
partitionnement par liste

partitionnement
Création table maître
SQL
CREATE TABLE mesure (
id_ville int not null,
date_trace date not null,
temperature int,
ventes int
);

partitionnement
Création des tables ﬁlles avec contraintes
SQL
CREATE 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);
...

partitionnement
Création des index
SQL
CREATE INDEX mesure_a2006m02_date_trace ON mesure_a2006m02 (date_trace);
...

partitionnement
Création des trigger
SQL
CREATE OR REPLACE FUNCTION mesure_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO mesure_a2008m01 VALUES (NEW.*);
RETURN NULL;
END;
$$
LANGUAGE plpgsql;
SQL
CREATE TRIGGER insert_mesure_trigger
BEFORE INSERT ON mesure
FOR EACH ROW EXECUTE PROCEDURE mesure_insert_trigger();

partitionnement
Attention à l’utilisation
SQL
rodo@[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)

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler
vaccum
materialized views
héritage de table
index

index
Il s’avère que la seule chose que les développeurs doivent
connaître est l’indexation. En fait, l’indexation d’une base de
données est un travail de développeurs car l’information la
plus importante pour une bonne indexation ne se situe ni au
niveau de la conﬁguration du système de stockage ni dans la
conﬁguration du matériel, mais plutôt au niveau de
l’application :
« comment l’application cherche ses données ».
Markus Winand - http://use-the-index-luke.com/fr

index
Trop d’index nuit à la performance. Mettre à jour un index qui n’est
jamais lu n’est pas forcément nécessaire.

index
Trop d’index nuit à la performance. Mettre à jour un index qui n’est
jamais lu n’est pas forcément nécessaire.
SQL
indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
--------------------+----------+--------------+---------------
job_job_fkposte_id | 0 | 0 | 0
job_job_region_id | 0 | 0 | 0
job_job_company_id | 43 | 323 | 305
job_job_author_id | 0 | 0 | 0
job_job_pkey | 22968 | 22930 | 22911
(5 rows)

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler
vaccum
materialized views
héritage de table
index
query

query
La ré-écriture des requêtes et le travail coté application

query
la requête la plus rapide est celle qui n’est pas éxecutée

query
rien ne sert de ré-écrire les index si les requêtes ne les utilisent
pas

query
rien ne sert de ré-écrire les index si les requêtes ne les utilisent
pas
certains axes d’optimisation ne sont pas compatible avec les
framework mal conçus

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler
vaccum
materialized views
héritage de table
index
query
???

Axes de travail
pgtune
hardware
tablespaces
replication
connection pooler
vaccum
materialized views
héritage de table
index
query
schema

schema
Last but not least, le schema reste la source numéro un des
problèmes de performance et de montée en charge.

schema
table

schema
table
view

schema
table
view
index

schema
table
view
index
"les jointures c’est bon mangez-en"

Conclusion

Conclusion
Tout modiﬁcation structurelle doit s’accompagner d’un processus de
validation itératif.

Conclusion
1 rédaction d’un protocole de test avec son jeu de données

Conclusion
2 mesure des indicateurs

Conclusion
3 modiﬁcation d’un paramètre

Conclusion
4 mesure des même indicateurs

Conclusion
5 analyse des résultats

Conclusion
5 analyse des résultats
6 goto 3 | 1

Questions ?
Rodolphe Quiédeville
rodolphe@quiedeville.org
http://blog.rodolphe.quiedeville.org/
Document publié sous Licence Creative Commons BY-SA 2.0

BBL autour de PostgreSQL @Novapost

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Plus de Rodolphe Quiédeville

Plus de Rodolphe Quiédeville (16)

BBL autour de PostgreSQL @Novapost