PostGIS in Action
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 68 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/30510 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
00:00
DatenbanksystemVorlesung/Konferenz
00:23
Open SourceProxy ServerOptimierungSoftwareYES <Computer>DatenstromDatenbankZugriffTabelleDatenbusChipkarteOpen SourceDatenbankDatensatzSoftwareFunktion <Mathematik>ZugriffInhalt <Mathematik>PolygonTabelleNamensraumKreisflächeDatenstromProzess <Physik>SkriptspracheErzeugendePunktPostgreSQLXMLVorlesung/KonferenzComputeranimation
05:07
DatenbankPolygonMaßstabTabelle
05:35
TabelleSQLAbfrageRegulärer Ausdruck <Textverarbeitung>Processing <Programmiersprache>OptimierungMail ServerRechteckIndexNormalePostgreSQLGeometrieCodeDatenbankDatentypGeometrieInformationOptimierungZeichenketteMAPChipkarteRetrievalspracheIndexLokales MinimumTabelleUnifikationstheorieAbfrageServerLogdateiViewerTyp <Informatik>Objekt <Kategorie>PostgreSQLWald <Graphentheorie>Folge <Mathematik>CodierungDatenbusHaar-MaßZahlenbereichMaßstabDEBUG <Programm>Quelle <Physik>Bindung <Stochastik>FlächentheorieComputeranimation
14:00
DatenbankIndexLaurent-ReiheQuelle <Physik>ViewerARM <Computerarchitektur>VerschneidungDienst <Informatik>BerechnungGebäude <Mathematik>MAPRetrievalspracheServerPostgreSQLComputeranimationVorlesung/Konferenz
14:56
RetrievalspracheTabelleZugriffSchnittmengeTropfenGeometrieInformationBiometrieFlächeChipkarteErzeugendeGruppoidPolygonStützpunkt <Mathematik>TabelleTransaktionMaßstabQuelle <Physik>FlächentheorieSicherungskopieZoomTyp <Informatik>p-BlockDatenbankRetrievalsprachePostgreSQLCachingComputeranimation
21:32
SchriftzeichenerkennungOptimierungZugriffTabelleSicherungskopieComputeranimation
23:02
ElementargeometrieEbeneRetrievalspracheTabelleViewerParallelisierungGeschwindigkeitFunktion <Mathematik>ErzeugendeIndexLaufzeitPolygonInternetVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:07
Wenn Jurist liest Datenbanken und Stadtpläne, dann denkt er, oh Gott, so viele Probleme. Deswegen freue ich mich jetzt, Postgiss in Action zu sehen, weil da sind garantiert keine rechtlichen Probleme versteckt und deswegen freue ich mich auf einen entspannten Vortrag.
00:23
Ja, vielen Dank, Falk und ja, hallo zu meinem Vortrag, Postgiss in Action. Ich würde heute ein bisschen aus dem Nähkästchen plaudern, wie wir Online-Karten mit Postgiss in den letzten Jahren umgesetzt haben auf Basis von OpenStreetMap und auch von amtlichen Daten. Kurz über mich,
00:40
bin Mitgründer mit Geschäftsführer von OmniScale aus Oldenburg, machen ja hauptsächlich Open Source Entwicklung im Geo-Bereich, Client- und Serverseitig, sind die Entwickler von MatProxy und Impossum, bieten da auch Support an, betreiben OpenStreetMap-Kartendienste und wie gesagt haben wir in den letzten Jahren auf Basis von ALKES,
01:01
also amtlichen Daten und OpenStreetMap-Daten, einige Kartendienste umgesetzt. Genau, Inhalt ein bisschen strukturiert, wie kriegen wir Daten rein, wie können wir Daten strukturieren, homogenisieren, optimieren und am Ende dann auch aktualisieren. Genau, kurzer Disclaimer,
01:21
einige Punkte dieser Präsentation sind nur relevant, wenn man auch ein bisschen mehr Daten hat. Wenn man jetzt ein Shapefile mit irgendwie fünf Punkten hat und man möchte das darstellen, dann ist das sind einige Punkte sicherlich nicht relevant. Also erst messen und dann eventuell handeln. Nur ganz kurz importieren, wie mit welchen Tools arbeiten wir da,
01:44
OSM arbeiten wir mit Impossum, das ist ein Tool, das wir auch selber geschrieben haben. Hintergrund, warum wir das selber geschrieben haben, sind einige Punkte, die ich in der Präsentation noch aufführen würde, Herr Werder. Für die ALKES-Daten benutzen wir PostNAS und OGR. Für andere Daten, sofern wir die haben, verwenden wir auch OGR und das Tool OGR2-OGR
02:08
und gelegentlich auch eigene Skripte, insbesondere zum Automatisieren von bestimmten Prozessen. Da Tipps, die ich da noch geben kann, ist, dass man die Dokumentation, sofern sie vorhanden ist, dass man sie lesen sollte
02:22
und die einzelne Option auch verstehen sollte, die eine Software so unterstützt. Und dass man Software auch aktuell halten sollte, kommen eigentlich auch immer neue Verbesserungen. Manchmal werden sie einfach automatisch schneller, manchmal haben sie aber neue Funktionen, die man dann auch einfach mal testen sollte.
02:40
Ein Beispiel für so eine versteckte Funktion, Postgres gibt es nicht nur Insert Statements, man kann mit Copy2 Datenstrom importieren, das ist typischerweise rund viermal so schnell. OGR2-OGR kann das schon lange mit dieser PGU-Copy-
03:01
Funktion oder Option, die man auf der Kommandozahle einfach übergibt, aber man muss sie aktivieren, diese Option, sonst profitiert man davon nicht. Beziehungsweise seit GDAL 2.0 ist es standardmäßig aktiv, aber vorher musste man tatsächlich die Dokumentation lesen, um dann da diesen Geschwindigkeitsvorteil zu bekommen.
03:21
Strukturieren. Man kann in Postgresql Tabellen strukturieren mit Schema. Damit sind nicht Datenbank-Schemas gemeint, das ist ein bisschen ungünstig benannt. In Postgres, die Schema, die ich jetzt meine, sind quasi Namespaces, also Namensräume.
03:41
Und wer in Kugis zum Beispiel schon mal eine Postgres-Datenbank importiert hat, der kennt vielleicht, dass es da irgendwie so ein Public -Schema gibt und das ist der Standard-Namensraum, in dem erst mal alle Tabellen landen. Und man kann dann aber auch neben diesem Public-Schema weitere Schemas erzeugen mit Create Schema. Und hier habe ich jetzt einfach mal zwei Schemas
04:03
erzeugt für OSM und für Alges-Daten. Und dann kann ich in jedem von diesen Schema, kann ich Tabellen erzeugen. Und die sind komplett unabhängig voneinander, das heißt, die können auch die gleichen Namen haben, diese Tabellen. Und Zugriff auf die Tabellen erfolgt dann über Schemaname.tabelle.
04:25
Und ein Projekt, was wir gerade umsetzen, Stadtplanwerk für den Regionalverband Ruhr, da geht es um Alges-Daten, also amtlichen Daten, die von 38 Kreisen kommen und zusätzlich noch mal OSM-Daten. Und was wir da machen, wir importieren einfach jeden einzelnen Datensatz komplett getrennt in einen eigenen Schema.
04:45
Und so können wir die halt komplett unabhängig voneinander betrachten. Wenn wir einen Datensatz komplett neu importieren, dann können wir aber dieses Schema aus der Datenbank löschen und neu importieren. Kommen wir jetzt zum Dateninterbellen strukturieren.
05:01
Wenn wir jetzt hier so eine Karte haben, dann möchten wir die Landnutzung darstellen. Und die haben wir jetzt in der Datenbank als Polygone. Und wir möchten aber jetzt in diesem Maßstab vielleicht gar nicht alle Polygone darstellen. Das heißt, hier sehen wir jetzt ganz viele kleine Polygone im Innenstadtbereich, das sind alles Gebäude, die können wir natürlich rausfiltern mit der Datenbank.
05:24
Bei der Anzahl von Polygonen hat die Datenbank trotzdem aber ein bisschen was zu tun. Und deshalb macht es Sinn, dass man jetzt für so einen Maßstab eine Tabelle hat, in dem diese Gebäudepolygone gar nicht drin sind. Deshalb optimal ist es, man hat eine Tabelle für einen Kartenlehr.
05:41
Das heißt, eine Tabelle für die Landnutzung, für Wasserflächen und halt eine Tabelle für die Gebäude. Und diese Tabelle und diesen Kartenlehr schalte ich halt einfach erst später zu, nämlich dann in dem Maßstab, wenn ich tatsächlich Gebäude zeichnen möchte. Das war ein Grund, weswegen wir im Postum entwickelt haben. Damit ist es nämlich möglich, genau diese bestimmte OSM-Datentypen in einer bestimmten Tabelle zu importieren.
06:06
Wie sieht das bei Alkes aus, also den amtlichen Daten? Da ist es so, wenn wir die mit PostNAS importieren, dann haben wir da ca. 30 Tabellen, in denen Objekte drin sind, die wir eigentlich für die Landnutzung auch haben möchten.
06:22
Und da komme ich jetzt zum nächsten Thema, zum Homogenisieren. Das heißt, wir möchten irgendwie das Vereinheitlichen. Und da ist jetzt ein Beispiel, für meine Online-Karte möchte ich jetzt irgendwie Wälder darstellen. Die sollen in irgendeinem Dunkelgrün dargestellt werden. Laub und Nadelholz ist mir eigentlich egal, das soll, wie gesagt, eine Farbe dargestellt werden.
06:44
Da habe ich dann das Problem, in den Alkes-Daten können die in drei Tabellen verteilt sein, AX-Wald, Gehölz und Vegetationsmerkmal. Und die Lösung, was ich dann umsetzen kann, ist, dass ich einfach drei Abfragen auf diese drei Tabellen mit einem Union-All einfach kombiniere.
07:03
Das heißt, ich habe hier meine Tabelle Wald, meine Tabelle Gehölz und die Tabelle Vegetationsmerkmal. Da sind auch noch ein paar andere Datentypen drin, deshalb muss ich da noch mal einen Filter machen. Die packe ich alle in einem Union-All. Und dann habe ich quasi eine SQL-Abfrage und kann die dann auch in einem Karten-Layer verwenden.
07:23
Das kann ich dann weiter fortsetzen für andere Landnutzung, für Friedhofsflächen, für irgendwelche Grasflächen etc. Und da kann ich dann eine zusätzliche Spalte hinzufügen, eine Typ-Spalte, mit der ich dann wieder die unterschiedlichen Typen unterscheide.
07:45
Sprich, wenn ich jetzt hier aus der Tabelle Wald-Daten lade, setze ich mir einfach den String Wald-S-Typ. Das heißt, ich definiere eine neue Spalte in diesem Query. Und für AX-Friedhof setze ich den Typ einfach als Friedhof.
08:00
Bei Tabellen, die jetzt Vegetationsmerkmal, wo verschiedene Typen drin sind, die ich im Endeffekt unterschiedlich darstellen möchte, da kann ich damit zum Case arbeiten. Case, when, the books und dann einer von diesen Alkes-Objektcodes. Dann soll das ein Wald sein und bei dem Code soll das halt Gras sein, vom Typ. Und im Karten-Styling muss ich dann einfach angeben, okay, Typ Wald bekommt dieses Grün, Typ Gras bekommt dieses Grün.
08:25
Das heißt, ich habe mein Karten-Styling deutlich vereinfacht. Also wenn wir zurückdenken, dass eigentlich die Waldflächen über drei Tabellen verteilt sind, ist das dann deutlich einfacher. Und im Endeffekt hat man dann tatsächlich ein Union-All über diese 30 AX-Tabellen.
08:43
Und statt diese komplexe Anfrage dann in dem Karten-Styling mitzuführen, also wenn wir jetzt mit Map-Server arbeiten wollen, dann müssten wir halt diesen Query in dem Map-File eintragen. Statt das zu tun, können wir halt auch einfach eine View erzeugen, in dem dann dieser komplexe Query enthalten ist.
09:05
Und ja, wie gesagt, im Map-Server sieht das Ganze dann so aus, dass ich dann einfach nur sage, okay, ich möchte jetzt die Geometrie von dieser View haben. Optimieren. Die Karten sollen natürlich dann auch wirklich schnell dargestellt werden.
09:22
Da wieder der Hinweis, erst messen und dann handeln. Für PostgreSQL gibt es generell so ein paar Tuning-Optionen, damit die Datenbank ein bisschen schneller wird. Ist jetzt weniger spezifisch OSM- und ALKES-Daten, deshalb gehe ich da gar nicht weiter drauf ein. Das sind so Stichwörter, nach denen man das ein bisschen suchen kann. Da gibt es eigentlich online viel Dokumentation, wo man darüber noch mehr Informationen findet.
09:50
Logging in Map-Server. Wenn man jetzt Map-Server verwendet, da ist es recht einfach mit diesen zwei Zeilen. Man geht quasi an, wo Map-Server loggen soll, und mit Debug 2 sagt man dem, dass für jeden Layer die Zeit gestoppt werden soll.
10:07
Wie lange der dafür braucht. Und das ist dann relativ einfach zu sehen. Okay, ich habe jetzt hier einen Layer, der ging irgendwie superschnell, und dann habe ich einen Layer, der hat jetzt irgendwie fast zwei Sekunden gedauert. Und so kann man dann sehen, wo es sich lohnt, Optimierung zu machen.
10:24
Typischerweise hat man zwei, drei Layer, die langsam sind, und der Rest ist eigentlich relativ schnell. Da ist das Logging von Map-Server recht hilfreich. Postgresql-Seite kann man auch Logging aktivieren. Das geht mit diesen drei Zeilen. Das Entscheidende ist hier Log Min Duration Statement.
10:44
Und wenn ich das setze, kann ich definieren, alle Statements, die mehr als in diesem Fall 50 Millisekunden benötigt haben, die sollen protokolliert werden. Und dann habe ich in dem Log, was ich konfiguriert habe, habe ich dann solche Zeilen drin, das steht dann, okay, Duration 1200 Millisekunden, und dann steht dahinter auch der komplette Select Statement,
11:08
der dann in dem Fall 1,2 Sekunden benötigt hat. Und da hat man dann auch wieder einen Angriffspunkt, um zu sehen, okay, hier muss ich vielleicht etwas optimieren. Man kann dann den Query auch einfach rauskopieren und auch einfach mal manuell ausführen.
11:25
In Postgresql Klein kann man einfach reinkopieren und ausführen. Man kann vielleicht einfach mal zählen, wie viele Objekte zurückgeliefert werden. Oder mit Explain Analyze sich von Postgresql selber erklären lassen, was die Datenbank im Hintergrund eigentlich tut.
11:47
Und da könnte man einen ganz eigenen Vortrag darüber machen. Das Entscheidende, man sieht am Ende, wie lange der dann tatsächlich gebraucht hat für diesen Query. Und man sieht hier so ein bisschen, dieser Begriff Sexscan, es ist ein Sequential Scan,
12:05
der bedeutet, dass die Datenbank die komplette Tabelle, Zeile für Zeile durchgelaufen ist. Und das ist eigentlich immer ein Indikator, dass man vielleicht, wenn die Anfrage länger gedauert hat, dass man da noch etwas optimieren kann. In dem Fall hatte ich jetzt den räumlichen Index einfach entfernt.
12:23
Im Normalfall ist dieser Index natürlich, sollte der da sein. Und wenn er da ist, dann sieht das Ganze so aus, dass man da dann in dem Fall den Indexscan hat. Und die Ausführungszeit dementsprechend auch akzeptabel ist. Also wie gesagt, wenn man langsame Queries hat, Explain, Analyze, einfach mal ausführen.
12:43
Und wenn man dann vielleicht sieht, okay, ein Sequential Scan war da, dann muss man vielleicht gucken, ob man da nochmal ein Index setzt. Vielleicht hat es aber auch eine andere Ursache. In so einem Mapfile trägt man in der Regel ein, okay, ich möchte die Geometrie von einem bestimmten Layer haben.
13:03
Was Map Server oder auch Geo Server etc. dann macht, ist, dass die Anfrage, die ich konfiguriert habe, eigentlich nur als Subselect verwendet wird. Und außenrum wird quasi dann nochmal eine räumliche Abfrage gemacht.
13:20
Weil wenn ich jetzt WMS oder wenn ich Kacheln zeichne, dann habe ich ja typischerweise immer nur einen kleinen räumlichen Ausschnitt. Und diese Abfrage, diese Filterabfrage, die wird hier nochmal extra drangehangen. Und PostgreSQL kann trotzdem in dem Fall auf den Geometrieindex zugreifen.
13:43
Wenn ich jetzt aber Folgendes habe, wenn ich jetzt mit dieser Geometrie noch was durchführen möchte, zum Beispiel ein Centroid berechnen möchte, dann wird von Map Server diese Abfrage heraus gemacht. Und das Problem ist, dieser Filter greift jetzt nicht mehr direkt auf die Tabelle zu, sondern auf diesem Ergebnis.
14:03
Und im Endeffekt muss die Datenbank dann für alle meine Gebäude das Centroid berechnen. Und dann wird erst überprüft mit diesem Envelope, also mit dieser Boundingbox, ob es da eine Verschneidung gab. Und das kann man sich vorstellen, dass es bei sehr vielen Gebäuden dann sehr lange dauert. Und da bieten jetzt zum Beispiel Map Server und auch Mapnik die Möglichkeit,
14:23
dass man in dem Query mit der Anführungszeichen Box bzw. Boundingbox bei Mapnik den Server dazu veranlasst, dass er die aktuelle Boundingbox von dem Ausschnitt in den Query mit rein kopiert.
14:42
Und da kann PostgreSQL dann wieder auf den räumlichen Index drauf zugreifen. Und damit ist dann auch diese Anfrage schnell. Materialized View ist sicherlich ein Punkt, den man sich anschauen kann. Ich glaube, die Zeit wird dazu ein bisschen knapp. Deshalb habe ich die letzten Folien gepackt.
15:01
Hier sehen wir jetzt die Folien, die URL ist auf der letzten Folie die URL von den ganzen Folien. Hier sehen wir Autobahn und Bundesstraßen. Und hier auch nochmal in Blau und da nochmal in Grün. Und man sollte da eigentlich nicht viel Unterschiede gesehen haben.
15:21
Wenn wir jetzt ein bisschen reinzoomen, dann sehen wir jetzt nochmal die gleichen Straßen. Aber ja, wie gesagt, ein bisschen weiter reingezoomt. Hier sehen wir jetzt nur die Geometrie. Und hier sehen wir schon, okay, ich habe hier irgendwie eine SQLite, eine PostgreSQL Funktion aufgerufen. Ich habe es nämlich vereinfacht, diese Geometrie.
15:42
Und hier an der Stelle sieht man schon deutlich, dass es da auf einmal sehr kantig wird. Und im Detail würde man das merken, dass hier Stützpunkte entfernt worden sind und dass die jetzt kantig geworden sind. Wenn ich aber eine Karte in diesem Maßstab zeichne, dann fällt das nicht auf. Dann merkt man das nicht.
16:03
Vorteil ist aber, man hat viel weniger Stützpunkte, die aus der Datenbank geladen werden müssen. Und das Zeichnen geht auch schneller. Und dieses Generalisieren mit ST Simplify, das kann man in dem Query selber durchführen. Man kann zusätzlich eine Tabelle auch erzeugen, die quasi eine Kopie von dieser Rhodes-Tabelle sich erstellt.
16:27
Und in dem Schritt könnte ich auch schon noch filtern, weil es natürlich Sinn macht. In der Karte, die ich hier gezeigt habe, sieht man natürlich keine Fußgängerwege und keine kleinen Straßen. Deshalb macht es Sinn, dass man beim Erzeugen von diesen generalisierten Tabellen
16:44
dann auch entsprechend nur die Daten reinbringt, die man auch zeichnen möchte. Und das ist auch eine Funktion, die wir mit Impostim implementiert haben. Das heißt, da kann man genau diese Tabellen konfigurieren, die schon dieses Simplify automatisch durchführen.
17:07
Kommen wir zur Landnutzung. Das sind jetzt alles Flächen, die eine bestimmte Landnutzung haben, die wir darstellen möchten. Das sind jetzt hier einfach Wohngebiete.
17:21
Und wir sehen, dass diese Daten, das sind jetzt amtliche Daten, die kommen eigentlich aus Flurstücksinformationen. Und wir sehen, dass sie sehr feinblätrig sind. Obwohl das jetzt hier alles einzelne Blöcke sind, die wir in der Karte mit der gleichen Farbe darstellen möchten, sind das doch sehr viele einzelne Polygone. Und die können wir vereinen mit S4Union, indem wir sie gruppieren nach dem Typ, also nach dem Typ, wie wir es nachher auch darstellen wollen.
17:48
Und dann sieht das Ganze so aus, dass wir da deutlich weniger Polygone haben. Das heißt, hier sieht man jetzt Polygone, die komplett keine inneren Flächen mehr haben. So sah das hier vorher aus.
18:02
Das heißt, dadurch kann man dann schon die Anzahl der Polygone, die der Kartenserver zeichnen muss, dann deutlich reduzieren. Und dann können wir auch die Generalisierung anwenden, also dieses Simplify. Das sieht dann so ein bisschen aus wie so ein Scherbenhaufen.
18:21
Aber es ist kein Problem, wenn man nämlich weiter rauszoomt und sich in so einem Maßstab befindet, dann fällt das gar nicht auf. Und man hat dann in diesem Maßstab Kartendaten, die, wenn man sie richtig einfärbt, dann auch schön aussehen und schnell gezeichnet werden können. Und das sind halt Sachen, die Orca MV oder, was ich eben gezeigt hatte, die Karte für den Stadtplanwerk, Regionalverband Ruhr.
18:47
Hier sieht man es nicht ganz so genau, aber man sieht alle Waldflächen, landwirtschaftliche Flächen etc., die tatsächlich auf den Flurstücken aufbauen,
19:00
werden hier innerhalb von einer Sekunde gezeichnet. Und das quasi auch schon ohne Caching. Und genau, sowas setzen wir quasi auf unsere Kartendienste ein. Und dann kann man da zeichnen, wie quasi alle Waldflächen, sieht es hier nicht so ganz gut, von Europa aus den USAM-Daten werden quasi auch innerhalb von einer Sekunde einfach gezeichnet.
19:25
Letzter Punkt jetzt, Aktualisieren von den Daten. Beim Aktualisieren sollte man typischerweise Transaktionen nutzen. Das heißt, ganz oder gar nicht. Wenn zwischendurch irgendwas abbricht bei dem Aktualisieren, dann hat man den Datenbestand vor dem Aktualisieren weiterhin.
19:48
Und man kann halt weiterhin auch auf den Datenbestand zugreifen. Das wird unterstützt von Impossum und seit OGR 2.0 geht das auch mit dieser DS-Transaction-Option.
20:05
Das wie gesagt beim Aktualisieren, wenn ich quasi nur Änderungen einspiele. Beim Neuimport von aktuellen Daten sollte man natürlich auch gucken, dass man auf Transaktionen zurückgreift, sodass die Nutzer während die neuen Daten importiert werden natürlich nicht irgendwie einen sich langsam aufbauenden Datenbestand sehen,
20:26
sondern dass sie noch den alten Datenbestand sehen. Und da muss man aber darauf warten, bestimmte Operationen, die bei einem typischen Neuimport durchgeführt werden, die blockieren dann das Lesen. Das heißt, selbst wenn ich eine Transaktion aufmache und mein Neuimport die Tabelle löscht und eine neue erzeugt,
20:47
dann kann währenddessen keiner mehr lesen darauf zugreifen. Deshalb ist da so die Alternative, dass man extra Import-Schema sich erzeugt und in diesen Import-Schema alle Tabellen, also die Daten neu importiert
21:02
und dann nachher durch Author-Table quasi das Schema ändert. Das heißt von meiner Tabelle, die jetzt in dem Fall in dem Public-Schema ist, das verschiebe ich in einen Backup-Schema und die neue Tabelle import verschiebe ich jetzt in meinen Public-Schema.
21:23
Und das Backup kann man dann nachher auch einfach löschen. Was man beachten muss, die Views zeigen dann auf die verschobene Tabelle. Das heißt, da muss man diese Views nochmal aktualisieren. Und das kann man jetzt zum Beispiel auch nutzen für Neuimporte mit OGR.
21:44
Da ist es so, man kann einfach das aktuelle Schema benennen, man importiert das, die Daten neu in das alte Schema und aktualisiert dann die Views und löscht dann einfach das alte Schema. Und so hat man quasi, während des kompletten Importvorgangs hat man weiterhin Zugriff auf den alten Datenbestand.
22:06
Und genau das ist auch das, was Impostum durchführt. Da wird auch in einem Import-Schema, wenn die Daten importiert, wenn man komplett neu Import durchführt. Und dann mit diesen Deploy-Protection werden diese Schemas automatisch umbenannt von Import zu Public und von Public zu Backup.
22:26
Zusammenfassend, ich habe aufgeführt, mit welchen Tools wir arbeiten, um die Daten zu importieren. Ich habe aufgezeigt, wie man mit Schemas die Daten strukturieren kann, mit Views Daten homogenisieren kann, mit ST Simplify und ST Union kann man Daten optimieren und beim Aktualisieren kann man auch wieder auf Schemas zurückgreifen.
22:49
Und genau, das war es dann mit meiner Präsentation. Wie gesagt, die Folien, die findet man hier.
23:03
Ja, recht vielen Dank für den Vortrag. Gibt es Fragen? Wie jetzt? Habt ihr schon Erfahrungen mit Parallelisierung, was seit 96 möglich ist in Sachen von OSM oder Alkis?
23:25
Parallelisierung von den Abfragen? Nee, haben wir noch keine Erfahrungen gemacht.
23:41
Diese Union-Operationen, sind die performant oder wirken die sich irgendwie aufs? Die sollte man nicht zur Laufzeit, also es kommt darauf an, wenn man auf kleinen räumlichen Ebenen ist, das heißt, wenn man selber reingezoomt ist, dann kann man die durchaus auch direkt in einem Query verwenden,
24:02
wenn man natürlich jetzt für so einen kompletten Kreis die Daten als Union zusammenstellt. Genau, wenn wir quasi diesen Schritt gehen, für so einen kompletten Kreis, um so etwas dann darstellen zu können,
24:26
dann macht das Sinn, dass man das quasi dann vorher macht oder es funktioniert von einer Geschwindigkeit, nur wenn man das vorher macht und entsprechend eine neue Tabelle erzeugt. Ich meine da eigentlich die Select-Unions, die am Anfang genannt wurden, die Union von den Select-Statements.
24:49
Genau, da war es. Ach so, das hier oder? Nee, weiter vor. Die Union All.
25:16
Ach so, da ist es so, auch wenn das aus 30 Tabellen besteht, dass der Geometrie-Index trotzdem für die einzelnen Tabellen durchgeleitet wird.
25:29
Von der Performance macht das quasi keinen Unterschied, ob ich 30 Select-Statements habe, wo ich jeweils einfach auf AX-Wall zurückreife und auf AX-Friedhof oder ich habe diesen Union All, da macht das keinen Unterschied.
25:46
So, gibt es noch weitere Fragen da hinten? Sonst hätte ich gesagt, Dominik hat bestimmt auch noch eine Frage, den interessiert das bestimmt, wie die das bei Omni-Scale machen.
26:15
Geht es jetzt? Du hattest da dieses ST Simplify gezeigt und das hat etwas lustige Polygone erzeugt.
26:25
Ich wollte sowas mal mit einer politischen Karte machen, mit Ländergrenzen und da ist das natürlich nicht so, sowas geht halt nicht. Gibt es da eine schlauere Funktion oder weißt du da was?
26:41
Nee, es gibt noch ST Simplify Preserved Topology, da könnte man bessere Ergebnisse erzielen, aber klar, wenn es optisch tatsächlich dann auch noch gut aussehen soll, dann wird es ein bisschen schwieriger.
27:01
In dem Fall ist es so, dass wir da eigentlich so weit raus tun, dass man es dann optisch gar nicht mehr sieht. Klar, geht in dem Fall natürlich. Danke.
27:26
Du hattest es nicht ganz angesprochen mit den Materialized Views, damit habe ich auch schon rumprobiert und da habe ich aber keine Möglichkeit Indizes zu benutzen. Wie benutzt ihr das, was für ein Szenario gibt es dafür?
27:46
Also ich bin dann immer auf den Drichter gekommen, dass ich dann doch Tabellen erstelle. Eigentlich müsste das funktionieren. Wir haben angefangen Materialized Views zu verwenden,
28:00
weswegen wir sie im Endeffekt nicht benutzt haben. Das sind quasi Views, die dauerhaft gespeichert werden als Kopie und die kann man aktualisieren. Das Problem ist nur, dass wir die Tabellen, die hinter dieser View stehen, nicht austauschen können, nicht aktualisieren können und deshalb sind wir hingegangen
28:21
und zeugen tatsächlich manuell eine Kopie mit Create Table. Vom Datenvolumen macht das keinen Unterschied zum Materialized View und Vorteil ist dann, dass wir die Daten dahinter tatsächlich komplett austauschen können.
28:41
Wir hatten das aktiv mit den Materialized Views auch getestet und es hätte mir auffallen müssen, wenn das mit den Geometrien nicht funktionieren würde. Okay. Also Aussage war, dass es keine Indizes gibt. Bin ich jetzt aktuell überfragt.