Komplex und schnell_20_min

453 views

Published on

Egal ob PostGIS oder Rasdaman - am Ende werden alle Anfragen in SQL an die Datenbank weitergegeben. Wie schnell die Datenbank die Anfragen bearbeitet liegt dabei sehr stark an den Algorithmen, die im SQL verwendet wurden. Bei über 95% aller Beschwerden, dass die Datenbank zu langsam ist, liegt die Ursache an einer ungünstig gewählten SQL-Zusammenstellung.
Der Vortrag zeigt auf, wie der PostgreSQL-Planer SQL-Anfragen verarbeitet, was der Unterschied zwischen INNER und OUTER Joins ist und wie SQL-Anfragen analysiert werden können. Darüber hinaus gibt es Tips und Tricks was zur Behebung langsamer Ausführungsschritte eventuell unternommen werden könnte. Vieles, des hier gezeigten, lässt sich auch auf andere Datenbanksysteme übertragen.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
453
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Komplex und schnell_20_min

  1. 1. Komplex und schnell? Machen Sie Ihrer PostgreSQL Beine! Susanne Ebrecht Westfalen 2013
  2. 2. Referentin Doktorandin Datenbankexpertin OpenSource Aktivistin Mehr als 25 Jahre Erfahrung in der Wirtschaft Seit vielen Jahren international tätig
  3. 3. Spielregeln Twitter @miraceesusanne Zwischenfragen sind Willkommen Keine Individualberatung Folien haben keine alleinstehende Aussagekraft
  4. 4. SQL Data Definition Language CREATE, ALTER, DROP Data Modification Language INSERT, UPDATE, DELETE Data Query Language SELECT Data Control Language GRANT, REVOKE Transaction Control Language START TRANSACTION, SAVEPOINT, COMMIT, ROLLBACK
  5. 5. Indizierung Gezielte Indizierung ... WHERE col1 = x AND col2 = y ein Index für col1, einer für col2 ... WHERE (col1, col2) = (x, y) ein Index für (col1, col2)
  6. 6. Joins B B A B A A B A A B INNER JOINOUTER JOINS LEFT JOIN RIGHT JOIN SELECT * FROM A JOIN B ON A.id=B.id; SELECT * FROM A, B WHERE A.id=B.id; SELECT A.* FROM A WHERE A.id IN (SELECT B.id FROM B); SELECT * FROM A LEFT JOIN B ON A.id=B.id WHERE B.id IS NULL SELECT * FROM A RIGHT JOIN B ON B.id=A.id WHERE A.id IS NULL B A B FULL JOIN A SELECT * FROM A FULL JOIN B ON A.id=B.id WHERE A.id IS NULL OR B.id is NULL
  7. 7. Schritt für Schritt A B C A B C A B C AB AC CB ABC ACB CBA
  8. 8. Planer EXPLAIN Planung EXPLAIN ANALYZE Planung + Ausführung
  9. 9. EXPLAIN knolle=# EXPLAIN SELECT s.stadt, k.verstoss, SUM(kv.betrag) AS gesamt FROM stadt AS s JOIN knoellchenvergabe AS kv ON s.kennzeichen=kv.stadt JOIN knoellchen AS k ON kv.verstoss=k.verstoss GROUP BY s.stadt, k.verstoss ORDER BY gesamt DESC LIMIT 10; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------- Limit (cost=4878.07..4878.10 rows=10 width=69) -> Sort (cost=4878.07..4941.18 rows=25245 width=69) Sort Key: (sum(kv.betrag)) -> GroupAggregate (cost=3827.64..4332.54 rows=25245 width=69) -> Sort (cost=3827.64..3890.75 rows=25245 width=69) Sort Key: s.stadt, k.verstoss -> Merge Join (cost=561.98..945.76 rows=25245 width=69) Merge Cond: (k.verstoss = kv.verstoss) -> Sort (cost=71.17..73.72 rows=1020 width=32) Sort Key: k.verstoss -> Seq Scan on knoellchen k (cost=0.00..20.20 rows=1020 width=32) -> Sort (cost=490.81..503.19 rows=4950 width=67) Sort Key: kv.verstoss -> Hash Join (cost=33.50..187.05 rows=4950 width=67) Hash Cond: ((s.kennzeichen)::text = (kv.stadt)::text) -> Seq Scan on stadt s (cost=0.00..19.90 rows=990 width=48) -> Hash (cost=21.00..21.00 rows=1000 width=37) -> Seq Scan on knoellchenvergabe kv (cost=0.00..21.00 rows=1000 width=37)
  10. 10. EXPLAIN ANALYZE knolle=# EXPLAIN ANALYZE SELECT ... QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=4878.07..4878.10 rows=10 width=69) (actual time=26.814..26.815 rows=10 loops=1) -> Sort (cost=4878.07..4941.18 rows=25245 width=69) (actual time=26.812..26.812 rows=10 loops=1) Sort Key: (sum(kv.betrag)) Sort Method: top-N heapsort Memory: 25kB -> GroupAggregate (cost=3827.64..4332.54 rows=25245 width=69) (actual time=25.631..26.597 rows=256 loops=1) -> Sort (cost=3827.64..3890.75 rows=25245 width=69) (actual time=25.617..25.712 rows=1000 loops=1) Sort Key: s.stadt, k.verstoss Sort Method: quicksort Memory: 125kB -> Merge Join (cost=561.98..945.76 rows=25245 width=69) (actual time=10.094..12.171 rows=1000 loops=1) Merge Cond: (k.verstoss = kv.verstoss) -> Sort (cost=71.17..73.72 rows=1020 width=32) (actual time=0.102..0.103 rows=13 loops=1) Sort Key: k.verstoss Sort Method: quicksort Memory: 25kB -> Seq Scan on knoellchen k (cost=0.00..20.20 rows=1020 width=32) (actual time=0.009..0.014 rows=13 loops=1) -> Sort (cost=490.81..503.19 rows=4950 width=67) (actual time=9.986..10.061 rows=1000 loops=1) Sort Key: kv.verstoss Sort Method: quicksort Memory: 125kB -> Hash Join (cost=33.50..187.05 rows=4950 width=67) (actual time=1.684..2.487 rows=1000 loops=1) Hash Cond: ((s.kennzeichen)::text = (kv.stadt)::text) -> Seq Scan on stadt s (cost=0.00..19.90 rows=990 width=48) (actual time=0.003..0.011 rows=21 loops=1) -> Hash (cost=21.00..21.00 rows=1000 width=37) (actual time=1.659..1.659 rows=1000 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 69kB -> Seq Scan on knoellchenvergabe kv (cost=0.00..21.00 rows=1000 width=37) (actual time=0.007..0.674 rows=1000 loops=1) Total runtime: 26.920 ms
  11. 11. ANALYZE knolle=# ANALYZE; knolle=# EXPLAIN ANALYZE SELECT s.stadt, k.verstoss, sum(kv.betrag) as gesamt FROM stadt as s JOIN knoellchenvergabe as kv ON s.kennzeichen=kv.stadt JOIN knoellchen as k ON kv.verstoss=k.verstoss GROUP BY s.stadt, k.verstoss ORDER BY gesamt desc LIMIT 10; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=67.39..67.42 rows=10 width=44) (actual time=5.586..5.590 rows=10 loops=1) -> Sort (cost=67.39..68.08 rows=273 width=44) (actual time=5.584..5.586 rows=10 loops=1) Sort Key: (sum(kv.betrag)) Sort Method: top-N heapsort Memory: 25kB -> HashAggregate (cost=58.77..61.49 rows=273 width=44) (actual time=5.080..5.240 rows=256 loops=1) -> Hash Join (cost=2.77..51.27 rows=1000 width=44) (actual time=0.084..2.812 rows=1000 loops=1) Hash Cond: (kv.verstoss = k.verstoss) -> Hash Join (cost=1.47..36.22 rows=1000 width=44) (actual time=0.048..1.716 rows=1000 loops=1) Hash Cond: ((kv.stadt)::text = (s.kennzeichen)::text) -> Seq Scan on knoellchenvergabe kv (cost=0.00..21.00 rows=1000 width=37) (actual time=0.008..0.326 rows=1000 loops=1) -> Hash (cost=1.21..1.21 rows=21 width=12) (actual time=0.028..0.028 rows=21 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 1kB -> Seq Scan on stadt s (cost=0.00..1.21 rows=21 width=12) (actual time=0.003..0.014 rows=21 loops=1) -> Hash (cost=1.13..1.13 rows=13 width=30) (actual time=0.027..0.027 rows=13 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 1kB -> Seq Scan on knoellchen k (cost=0.00..1.13 rows=13 width=30) (actual time=0.008..0.015 rows=13 loops=1) Total runtime: 5.686 ms
  12. 12. PGAdminIII
  13. 13. explain.depesz.com Hubert Lubaczewski, Nickname: depesz
  14. 14. explain.depesz.com Hubert Lubaczewski, Nickname: depesz
  15. 15. Analyse • (cost=0.00..19.90 rows=990 width=48) (actual time=0.003..0.011 rows=21 loops=1) • ANALYZE oder STATISTIC TARGET • (actual time=10.081..15.764 rows=1000 loops=651) • Logik überdenken, Umgestaltung der Anfrage, ggf. CTE (CommonTable Expression) • (actual time=25.617..12425.712 rows=1000 loops=1) • Logik überdenken, Umgestaltung der Anfrage, ggf. Indizierung
  16. 16. Seq Scan Tabelle Page 1 Page 2 Page 3 ... Page n Sychronize Seqscan Page 1 Page 2 Page 3 ... Page n
  17. 17. Index Scan B-Baum Blatt 1 Blatt 2 Blatt 3 ... Blatt n Tabelle Page 1 Page 2 Page 3 ... Page n Wurzel
  18. 18. Bitmap-Index-Scan B-Baum Blatt 1 Blatt 2 Blatt 3 ... Blatt n Tabelle Page 1 Page 2 Page 3 ... Page n Wurzel 0 1 1 0 0 0 0 1 0 0 1 1 0 0 0 0 0 1 1 0 1 0 1 1 0 0 0 1 0
  19. 19. Geschwindigkeit Tabellengröße Antwortzeit Seqscan Indexscan Bitmapscan
  20. 20. Nested Loop Index A Blatt 1 Blatt 2 Blatt 3 ... Blatt n Tabelle A Page 1 Page 2 Page 3 ... Page n Wurzel Index B Blatt 1 Blatt 2 Blatt 3 ... Blatt n Tabelle B Page 1 Page 2 Page 3 ... Page n Wurzel
  21. 21. Merge Join 1. Datensatz 2. Datensatz Voraussetzung: Sortierte Datensätze
  22. 22. Hash Join 1. Datensatz 2. DatensatzHash Lookup •Hash wird erzeugt und zum Joinen genutzt •Verknüpfung von großer und kleiner Tabelle •Hoher work_mem •Notfall-Mechanismus schützt vor Speicherüberlauf
  23. 23. Langsam SELECT COUNT Aggregate MIN(), MAX(), ... DISTINCT SELECT COUNT (DISTINCT ...) Correlated Subselects INNER JOINS schneller als OUTER
  24. 24. Zusammenfassung Gezielt Denormalisieren Gezielt Indizieren Prüfen ob ANALYZE gelaufen ist EXPLAIN ANALYZE zur Analyse INNER schneller als OUTER Aggregate und DISTINCT sind langsam

×