Hallo!
Das geht schon, allerdings sind einige Vorüberlegungen nötig.
1. Was sind das denn für Daten? Sind das große Geometrien oder nur Punkte? Mit Groß mein ich >200000 Punkte pro Polygon oder so. Hier könnte eine Aufbereitung nach Douglas-Poiker o.ä Abhilfe schaffen, wenn möglich.
2 . Wie sollen sie abgefragt werden? Eventuell ist eine Partitionierung der Tabelle nützlich. wenn z.B. oft nach Postleitzahlen abgefragt wird, ist ggf. eine solche Partitionierung nach Postleitzahlbereichen nützlich.
3.Eminent wichtig ist hier die Verwendung von Indices, die die Suchanfragen auch unterstützen. Vor allen ein Index auf die Geometrie ist hier sehr wichtig, z.B. wenn eine WMS-Abfrage stattfinden soll.
4. Hast du viele teure Union/Intersect etc- Abfragen, ist es ggf. sinnvoll große Geometrien in Abschnitte zu zerteilen. Das ist zwar mit Geos3.1 sehr viel schneller geworden, aber halt immer noch recht teuer.
5. Überprüfen, wie mit den Daten gearbeitet werden soll. Eventuell ist es sinnvoll, den einzelnen Bearbeitern Auszüge in einer eigenen Datenbank bereitzustellen.
Das kann man alles weitgehend auch automatisieren. Der (einmalige) Import ist halt was, wo man schwer drumrum kommt
Wie liegen die Daten denn vor? Tabellen oder Shapes? Schreibst du per Copy oder Insert?
Was ganz kritisch wird, sind die 4GB. Da sollten schon 8 oder mehr draus werden, vor allem, wenn noch was anderes da laufen sollte oder umfangreiche Abfragen stattfinden. Zum Feintuning von shared_mem oder work_mem kommt aber bestimmt auch noch was.
Soviel erst mal...
Gruß Uwe



LinkBack URL
About LinkBacks
Zitieren
. Hier könnte eine Aufbereitung nach Douglas-Poiker o.ä Abhilfe schaffen, wenn möglich.


Lesezeichen