Anzeige:
Seite 2 von 2 ErsteErste 12
Ergebnis 16 bis 20 von 20

Thema: Besitzt Postgres eine ausreichende Performance?

  1. #16
    Registrierter Benutzer
    Registriert seit
    22.06.1999
    Beiträge
    677
    Zitat Zitat von Dellerium
    Die Frage ist nun, ab wann eine Menge als unnormal gross bezeichnet wird... gehe ich mal von 100.000 Datensätzen aus, dann macht das innerhalb von einem Jahr 36.500.000 Datensätze.
    Wie lange willst Du deine Daten denn aufheben? Wenn Du Sie z.B. ein Jahr aufhebst, dann Kann z.B. ein Bitmap Index (hat die neueste PG Version 8.1) auf den Monat die Abfrage nach Monaten unglaublich beschleunigen.

    Andererseits ändern sich alte Daten ja nicht. Also würde ich empfehlen, vorverdichtete Daten (z.B. pro Tag) zu berechnen und in Tabellen zu speichern. Wiel die Daten sich nicht ändern ist Redundanz kein Problem.

  2. #17
    Registrierter Benutzer Avatar von elrond
    Registriert seit
    04.10.2001
    Ort
    potsdam
    Beiträge
    881
    die antwort darauf könnte eine regelmäßige verdichtung der Daten sein. so.

    btw denke ich nicht, dass die 36 mio Datensätze die sache fürchterlich langsam machen. Allerdings wird eine solche db sehr "unhandlich" bzgl. Datensicherung / Kopie auf Testsystem usw.
    "Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)

  3. #18
    Registrierter Benutzer
    Registriert seit
    19.02.2005
    Beiträge
    23
    Zitat Zitat von elrond
    die antwort darauf könnte eine regelmäßige verdichtung der Daten sein. so.

    btw denke ich nicht, dass die 36 mio Datensätze die sache fürchterlich langsam machen. Allerdings wird eine solche db sehr "unhandlich" bzgl. Datensicherung / Kopie auf Testsystem usw.
    Ich kann die Daten nicht verdichten, bzw. darf es nicht. Die Daten - auch wenn es sehr viele sind - müssen exakt so vorliegen wie sie gesammelt wurden.

    Die 36 mio Datensätze ware nur ein Beispiel... es kann auch wesentlich mehr, oder wesentlich weniger sein. Was das angeht bin ich aber Pessimist - deshalb soll es lieber mit noch wesentlch grösseren Datenmengen umgehen können. Sagen wir einfach Faktor 10 grösser.

    Das das Handling der Daten dann nicht einfach wird ist klar. Das merke ich schon bei einer anderne DB die wir hier im Einsatz haben. Da dauert das Einspielen eines Dumps im günstigsten Fall 1,5 Stunden wenn fsync aus ist... sonst die doppelte bis dreifache Zeit.


    @Christoph: Das mit dem Bitmap Index werde ich mir einmal anschauen, danke.

  4. #19
    Registrierter Benutzer
    Registriert seit
    15.10.2005
    Ort
    Franken
    Beiträge
    362
    Im Umgang mit derart großen (um nicht zu sagen "gigantischen") Datenbeständen geben sich MySQL und PostGres nicht viel. So ist es jedenfalls bei 85 Mio Datensätzen (ebenfalls Logs, täglich kommen bis zu 75000 dazu) mit 5 Spalten mit einem FK-Index.

    Schneller dagegen waren der MS SQLserver und MaxDB (ca. 1,5 Sekunden (ca. 40%) schneller bei ner Select mit 2 Where-Bedingungen)
    MaxDB ist auf Auswertungen ausgerichtet, da es speziell als Backend für SAP-Systeme ausgelegt ist, welches ja in größeren Firmen auch sehr viele Daten analysieren muss. Bei den Inserts war der SQLserver geringfügig schneller.

    Die Benchmarks wurden von meiner Firma vor etwa einem Jahr durchgeführt, dabei sind wir von Oracle (wegen Unzufriedenheit mit dem Support) auf ein anders System umgestiegen.

    Letztendlich haben wir uns für den SQL-Server entschieden, da die Logs zwar erhalten bleiben mussten, aber für Auswertungen ein Cron die Daten verdichten konnte (jewails auf Tage und auf Monate).

    Ist das bei dir nicht der Fall, würde ich mir MaxDB mal ansehen.

    Backups machten übrigens mit keinem der Systeme Schwierigkeiten, nur bei MySQL lies sich ein Backup erst beim 2. Versuch einspielen. War aber ein Einzelfall.

    EDIT:
    Noch n Tipp: Immer so Arbeiten, dass man die Datenbank austauschen kann, ohne am Code was ändern zu müssen. Sprich: Nur nach SQL 99 oder 03 arbeiten.
    Geändert von Turbohummel (16-11-2005 um 22:41 Uhr)
    Dank der Rekursion kann ich IF-Schleifen bauen.

    In neuem Glanz: www.turbohummel.de

  5. #20
    Registrierter Benutzer
    Registriert seit
    19.02.2005
    Beiträge
    23
    Zitat Zitat von Turbohummel
    Im Umgang mit derart großen (um nicht zu sagen "gigantischen") Datenbeständen geben sich MySQL und PostGres nicht viel. So ist es jedenfalls bei 85 Mio Datensätzen (ebenfalls Logs, täglich kommen bis zu 75000 dazu) mit 5 Spalten mit einem FK-Index.

    Schneller dagegen waren der MS SQLserver und MaxDB (ca. 1,5 Sekunden (ca. 40%) schneller bei ner Select mit 2 Where-Bedingungen)
    MaxDB ist auf Auswertungen ausgerichtet, da es speziell als Backend für SAP-Systeme ausgelegt ist, welches ja in größeren Firmen auch sehr viele Daten analysieren muss. Bei den Inserts war der SQLserver geringfügig schneller.

    Die Benchmarks wurden von meiner Firma vor etwa einem Jahr durchgeführt, dabei sind wir von Oracle (wegen Unzufriedenheit mit dem Support) auf ein anders System umgestiegen.

    Letztendlich haben wir uns für den SQL-Server entschieden, da die Logs zwar erhalten bleiben mussten, aber für Auswertungen ein Cron die Daten verdichten konnte (jewails auf Tage und auf Monate).

    Ist das bei dir nicht der Fall, würde ich mir MaxDB mal ansehen.

    Backups machten übrigens mit keinem der Systeme Schwierigkeiten, nur bei MySQL lies sich ein Backup erst beim 2. Versuch einspielen. War aber ein Einzelfall.

    EDIT:
    Noch n Tipp: Immer so Arbeiten, dass man die Datenbank austauschen kann, ohne am Code was ändern zu müssen. Sprich: Nur nach SQL 99 oder 03 arbeiten.
    Hallo und danke für die Infos

    Im Moment mache ich das so, das ich mich soweit es irgendwie geht nach SQL99 richte und die Datenbankzugriffe über eine extra Klasse kapsele. Ich bereite das System schon darauf vor, durch weitere Klassen auch andere Datenbanken anbinden zu können.

Lesezeichen

Berechtigungen

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