Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: Sehr große Datanbank machbar? Tipps?

  1. #1
    tklemmer ist offline Neuer Benutzer
    Registriert seit
    10.08.2011
    Beiträge
    15

    Standard Sehr große Datanbank machbar? Tipps?

    Hallo,


    ich habe den Auftrag 1 Mrd. (1.000.000.000) Datensätze (a 25 Felder) in einer Datenbank zur Verfügung zu stellen. Da die Daten alle georeferenziert sind soll das ganze mit PostGis passieren.
    Ich habe einen Ubuntu 10.4 Server (i3, 4GB Ram, 1TB HDD) mit einer fertige PostGis Datenbank (Standard Einstellungen).
    Einen Importer habe ich auch schon geschrieben...

    Jetzt bekomme ich aber doch ein bissel kalte Füße da der Import sicher mehrere Tage dauern wird...

    Kann die Datenbank mit 1 Milliarde Einträgen umgehen?
    Kann ich diese alle in eine Tabelle packen oder ist es sinnvoll mehrere Tabellen / Datenbanken zu nutzen?
    Wie kann ich die Performance optimieren?

    Die Tabelle wird danach nicht mehr verändert und es greifen auch maximal 2 bis 3 Nutzer gleichzeitig darauf zu.

    Ich bin alle Tipps und Erfahrungen dankbar!

    Gruß TK

  2. #2
    Gisman ist offline Erfahrener Benutzer
    Registriert seit
    20.01.2006
    Ort
    Pfalz
    Beiträge
    794

    Standard

    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
    Have a lot of fun!

  3. #3
    tklemmer ist offline Neuer Benutzer
    Registriert seit
    10.08.2011
    Beiträge
    15

    Standard

    Hallo Gisman,

    Ersteinmal danke für die Antwort, ich bin was Datenbanken angeht leider noch ein unbeschriebens Blatt...
    Bei den Daten handelt es sich nur um Punkte. Diese liegen als CVS Dateien vor (20000 Dateien mit so durchschnittlich 50000 Einträgen).
    Diese werden alle per INSERT eingetragen.

    Später sollen mit einer Gui anhand einer Kartenansicht Datensätze generiert werden wie z.B. alle Messpunkte innerhalb eines Radiuses um eine Koordinate oder
    alle Punkte die an einer Strecke von Koordinate A nach B liegen. Diese kleineren Datensätze werden dann separat verarbeitet.

    Ich hatte vor den Index nach dem Import anhand der Geometrie zu erstellen!

    Die Datenbank wird nach der Erstellung nicht mehr geändert sprich es muß keine neue Indizierung stattfinden....

    Die 4GB sind sicher nicht genug da werden wohl noch mal 4 oder gar 8 GB folgen, ich habe einiges über shared Buffer gelesen gibt es dazu Tips?

    Viele Grüße
    TK

  4. #4
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.472

    Standard

    Zitat Zitat von tklemmer Beitrag anzeigen
    Hallo Gisman,

    Ersteinmal danke für die Antwort, ich bin was Datenbanken angeht leider noch ein unbeschriebens Blatt...
    Bei den Daten handelt es sich nur um Punkte. Diese liegen als CVS Dateien vor (20000 Dateien mit so durchschnittlich 50000 Einträgen).
    Diese werden alle per INSERT eingetragen.

    Später sollen mit einer Gui anhand einer Kartenansicht Datensätze generiert werden wie z.B. alle Messpunkte innerhalb eines Radiuses um eine Koordinate oder
    alle Punkte die an einer Strecke von Koordinate A nach B liegen. Diese kleineren Datensätze werden dann separat verarbeitet.

    Ich hatte vor den Index nach dem Import anhand der Geometrie zu erstellen!

    Die Datenbank wird nach der Erstellung nicht mehr geändert sprich es muß keine neue Indizierung stattfinden....

    Die 4GB sind sicher nicht genug da werden wohl noch mal 4 oder gar 8 GB folgen, ich habe einiges über shared Buffer gelesen gibt es dazu Tips?

    Viele Grüße
    TK
    Die Faustregel ist etwa 25% vom RAM als Shared Buffers zu nehmen. Aber je nach workload können da auch andere Werte sinnvoll sein. Und es gibt noch ein paar andere Parameter.

    Falls es die Daten und die Abfragen zulassen, solltest Du über Normalisierung und table-partitioning nachdenken.

    Ach ja: INSERT bei der Menge an Daten ist absolut suboptimal. Wenn die als CSV vorliegen, dann nehme COPY.


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  5. #5
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    Bei der Menge Daten macht 25% nur noch wenig Sinn. In der Regel wirst du bei Scans über diese Datenmengen die Tabellen immer und immer wieder durchlaufen und dein Cache ist regelmäßig leer.
    Das ganze ist ein typisches Data Warehouse Problem und keine OLTP-Betrachtung mehr.

    Wie akretschmer sagt: probier dich mit COPY, das beschleunigt zumindest das Einlesen.
    Für den täglichen Betrieb müsste man aber im Detail schauen, was man wo optimieren kann ...

    Ich sage jetzt hier nicht, das meine Firma für so etwas fertige Lösungen hat ;-)
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  6. #6
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.472

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Bei der Menge Daten macht 25% nur noch wenig Sinn. In der Regel wirst du bei Scans über diese Datenmengen die Tabellen immer und immer wieder durchlaufen und dein Cache ist regelmäßig leer.
    Und, was würdest Du empfehlen?

    IMHO ist es relativ egal, ob 25% oder auch 50%, die 4GByte reichen so oder so nicht wirklich. Aber: es kommt auch auf die Abfragen an, insbesondere, ob diese passende Indexe nutzen können. Falls ja, wäre das alles noch nicht dramatisch, aber falls Abfragen ohne Indexe da laufen wird es böse. Egal, wieviel % man für Shared nimmt. Und ja: ich bezweifle, daß Euer Produkt zaubern kann ...


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  7. #7
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    Es zaubert nicht, es parallelisiert.
    Es macht in der Größenordnung keinen Sinn mehr, alles im Shared Buffers halten zu wollen.
    Statt dessen möchte man die Daten möglichst schnell zu einer oder mehreren CPUs zum Scannen bekommen.

    Komm zur FrOSCon, ich zeige dort, wie das geht ;-)
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  8. #8
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.472

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Es zaubert nicht, es parallelisiert.
    Es macht in der Größenordnung keinen Sinn mehr, alles im Shared Buffers halten zu wollen.
    Statt dessen möchte man die Daten möglichst schnell zu einer oder mehreren CPUs zum Scannen bekommen.

    Komm zur FrOSCon, ich zeige dort, wie das geht ;-)
    Darf ich mal aus dem Ursprungsposting zitieren?

    "Ich habe einen Ubuntu 10.4 Server (i3, 4GB Ram, 1TB HDD)"

    Unter dieser Bedingung könnt Ihr wohl kaum "die Daten möglichst schnell zu ... mehreren CPUs zum Scannen bekommen", oder?


    Aber wenn wir schon mal dabei sind: könnt ihr (auf einem Eisen) mehrere CPU's für eine Anfrage nutzen? Das wäre dann allerdings (eventuell) ein echtes Plus...



    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  9. #9
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    Zitat Zitat von akretschmer Beitrag anzeigen
    Aber wenn wir schon mal dabei sind: könnt ihr (auf einem Eisen) mehrere CPU's für eine Anfrage nutzen? Das wäre dann allerdings (eventuell) ein echtes Plus...
    Ja, Greenplum kann das.

    Generell - und das ist keine Greenplum Eigenheit - ist bei Data Warehouse typischen Anfragen das Disk I/O das Limit.
    Du musst halt durch zu viele Daten möglichst schnell durch ... das ist ein beträchtlicher Unterschied zur OLTP-Welt.
    Mit dem Gedanken hatte ich Anfangs (sprich: als ich bei Greenplum angefangen habe) auch ganz schön zu kämpfen.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  10. #10
    Gisman ist offline Erfahrener Benutzer
    Registriert seit
    20.01.2006
    Ort
    Pfalz
    Beiträge
    794

    Standard

    Guten Morgen!

    Zitat Zitat von tklemmer Beitrag anzeigen
    Später sollen mit einer Gui anhand einer Kartenansicht Datensätze generiert werden wie z.B. alle Messpunkte innerhalb eines Radiuses um eine Koordinate oder
    alle Punkte die an einer Strecke von Koordinate A nach B liegen. Diese kleineren Datensätze werden dann separat verarbeitet.
    Hier kann auch optimiert werden. Was ist denn das für eine GUI? Desktop-GIS oder Webmapping? Man könnte überlegen, die Massendaten per WMS auch für das DesktopGIS bereitzustellen. Grund: Wenn man Die Tabelle als Tabelle einliest, muß die komplett gelesen werde, das dauert ewig. Der WMS liest nur das, was im Auschnitt liegt. Attribute können dann ggf. über einen WFS bereitgestellt werden, was auch schnell ist, da sehr präzisse in der Tabelle gesucht werden kann.
    Nach deiner Beschreibung brauchst du einige Buffer- und Intersect-Abfragen, das ist nicht unbedingt billig zu haben. Es ist also sinnvoll, diese kleineren Datensätze ebenfalls in PostGIS bereitzustellen. Hier könnte sich ggf. noch die Möglichkeit bieten über Views oder materialized Views komplexere Abfragen vorzubereiten, vor allem wenn sich die Daten nicht mehr ändern. Auch könnte sich eine Optmierung der Daten als vorteilhaft erweisen, z.B. um unnötige Punkte in Linien zu entfernen (bremst Buffer aus z.B.).
    Allerdings ist hier bei allem schon ein Limit durch die Hardware gesetzt.

    Viele Grüße
    Uwe
    Have a lot of fun!

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Frage Differentielles Backup machbar?
    Von dsteinwe im Forum Allgemeines
    Antworten: 6
    Letzter Beitrag: 03.05.2011, 15:15
  2. Frage zu Indexen und Performance Tipps
    Von sly im Forum Allgemeines
    Antworten: 19
    Letzter Beitrag: 22.11.2010, 21:30
  3. Große Forenumstellung
    Von Xandrian im Forum Neuigkeiten & Ankündigungen
    Antworten: 30
    Letzter Beitrag: 18.08.2010, 13:02
  4. Große Datenbanken
    Von Ymris im Forum Allgemeines
    Antworten: 10
    Letzter Beitrag: 19.12.2008, 09:35
  5. Große DB mit Bildern
    Von Matrix-NTN im Forum Allgemeines
    Antworten: 4
    Letzter Beitrag: 04.04.2008, 22:39

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum