LeKuchen: Wie optimieren DMS den Zugriff?

Hallo zusammen,
ich habe mich gerade gefragt, wie Datenbankmanagementsysteme eigentlich die Zugriffe auf die Daten optimieren.

Nehmen wir an, wir haben 1.000.000 Datensätze mit einem Datumsfeld. Diese werden per SQL abgefragt nach einem Datum zwischen 1.1.2004 und 7.1.2004.
Was passiert jetzt im DMS? Schaut das DMS das Feld in jeder Zeile nach und checkt auf die Bedingung? Wie optimieren die solche Prozesse? Und: Inwiefern spielt die Hardware bei der Abfragezeit eine Rolle?

Dazu habe ich in wikipedia nix gefunden....Wäre nett, wenn mir das jemand erklären könnte bzw. Links.

Gruß,
LeKuchen

  1. Moin!

    ich habe mich gerade gefragt, wie Datenbankmanagementsysteme eigentlich die Zugriffe auf die Daten optimieren.

    Unterschiedlich, würde ich meinen. :)

    Nehmen wir an, wir haben 1.000.000 Datensätze mit einem Datumsfeld. Diese werden per SQL abgefragt nach einem Datum zwischen 1.1.2004 und 7.1.2004.
    Was passiert jetzt im DMS? Schaut das DMS das Feld in jeder Zeile nach und checkt auf die Bedingung? Wie optimieren die solche Prozesse? Und: Inwiefern spielt die Hardware bei der Abfragezeit eine Rolle?

    Der Programmierer der Datenbank ist für die Optimierungen mit verantwortlich. Wenn das Datum des Datensatzes wichtig für diverse SELECT-Operationen ist, empfiehlt es sich, auf diese Spalte einen Index zu setzen. Dann kann die Datenbank sehr schnell mithilfe dieses Indexes die relevanten Datensätze herausfinden und muß dann nur noch diese von der Festplatte einlesen.

    Wenn die Datumsspalte aber keinen Index hat, dann wird tatsächlich die gesamte Datenbank Datensatz für Datensatz durchgelesen und auf Übereinstimmung mit dem gewünschten Kriterium geprüft - und daran gibt es auch nur recht wenig zu optimieren, das dauert eben einfach so lange, wie es dauert.

    Andererseits bringt es nichts, einfach auf alle möglichen Spalten einen Index zu setzen. Denn die Pflege dieses Indexes ist auf Aufwand. Zum einen verbraucht ein Index seinerseits doch erheblich Speicher, zum anderen wird der eben auch nicht zum Nulltarif aktualisiert, sondern das benötigt ebenfalls Zeit. Eine Datenbank mit vielen Indizes in einer Tabelle ist also sehr schnell bei jeglichem Lesezugriff, weil vermutlich immer ein Index für die WHERE-Bedingung zur Verfügung steht, aber sie ist sehr langsam bei UPDATE oder INSERT, weil sehr viele Indizes aktualisiert werden müssen.

    Deshalb ist es nicht in jedem Fall sinnvoll, wie wild Indices auf eine Tabelle zu verteilen.

    Ebenfalls ist entscheidend, welche Art von Daten denn in der Spalte stehen. Ein Index auf eine Spalte, die nur die Werte "ja" oder "nein" annehmen kann, ist relativ sinnlos, denn die Datenbank erhält hier fast keinerlei Vorteil durch einen Index, weil die möglichen Werte in der Spalte nicht sehr unterschiedlich sind. Ein Index z.B. auf einen Namen hingegen ist absolut sinnvoll, denn das Alphabet hat je Stelle ja mindestens mal 26 verschiedene Buchstabenmöglichkeiten - das potenziert sich mit der Stringlänge, so dass ein Index hier sehr hilfreich wirken kann.

    - Sven Rautenberg

    1. Moin!

      Der Programmierer der Datenbank ist für die Optimierungen mit verantwortlich. Wenn das Datum des Datensatzes wichtig für diverse SELECT-Operationen ist, empfiehlt es sich, auf diese Spalte einen Index zu setzen. [..]

      Genau!

      kleine Ergänzung vielleicht noch: ein Index greift effektiv wenn eine WHERE Klausel angewandt wird.

      In MySQL kannst Du mit einem, dem SELECT vorangestellten EXPLAIN auch ganz gut sehen, was da passiert und wo noch optimiert werden kann:

      SELECT * FROM tab WHERE id='123';  nunmehr:
      EXPLAIN SELECT * FROM tab WHERE id='123';

      ... zeigt Dir dann an, welche Indexe verwendet werden (oder nicht).

      --Rolf

      1. Hallo,

        ... zeigt Dir dann an, welche Indexe verwendet werden (oder nicht).

        Sehr cooler Hinweis....Danke!
        -LeKuchen

    2. Tachgesacht,

      Unterschiedlich, würde ich meinen. :)

      Naja, das denk ich mir ;o). Gibt ja schnelle und weniger schnelle DMS....

      Dann kann die Datenbank sehr schnell mithilfe dieses Indexes die relevanten Datensätze herausfinden und muß dann nur noch diese von der Festplatte einlesen.

      Jo, Indices habe ich mir auch gedacht. Aber: Letztens mit einem DMS (Access - hihi) eine ähnliche Abfrage wie oben beschrieben versucht. Dauerte sehr lange. Dann einfach mal in die Tabelle noch die KW geschrieben und selbe Abfrage nach KW gemacht. Dauerte ebenso lange!

      Eine weitere Frage ist: Sind Indices die einzige Methode der DMS Entwickler um Abfragen in DMS zu optimieren? Warum dann solche Geschwindigkeitsunterschiede bei Abfragen zwischen den DMS bei großen Datenmengen? Industrieunternehmen werden bei riesigen Datenmengen doch nicht Datenbankabfragen haben, bei denen - neben Indices-Abfragen - Datensatz nach Datensatz abgefragt wird?!? Schreiben müssen die ja auch ne Masse Daten. Das würde ja ewig dauern...

      Wie ist das mit Caching? Werden häufig gestelle Abfragen gecacht? (Denke ich mir zumindest.)

      Und: Was bringt in diesem Fall Arbeitsspeicher? Bringt es was, wenn der Server z.B. die gesamte Datenbank im Speicher halten kann?

      Gruß & Danke,
      LeKuchen

      1. Hi,

        Naja, das denk ich mir ;o). Gibt ja schnelle und weniger schnelle DMS....

        schweinchenschlaumodus_anfang:
        (DMS == document managing system)
        (DBMS == database managing system)
        schweinchenschlaumodus_ende:

        Gruss,
        Ludger

        --
        "(SPD == Sie pluendern Deutschland)"
        1. Hu,

          schweinchenschlaumodus_anfang:
          (DMS == document managing system)
          (DBMS == database managing system)
          schweinchenschlaumodus_ende:

          Ne, hast ja Recht, ich wollte eigentlich sagen:
          (DBS == database system).
          Ein DBMS alleine bringt es ja auch nicht! ;o)
          http://de.wikipedia.org/wiki/Datenbank

          Gruß,
          LeKuchen

          1. Hi,

            Ein DBMS alleine bringt es ja auch nicht! ;o)
            http://de.wikipedia.org/wiki/Datenbank

            das erinnert mich an was:
            http://forum.de.selfhtml.org/archiv/2002/10/t27173/#m148090

            Gruss,
            Ludger

            --
            "Die SPD im Aufwind?"
    3. yo,

      Ein Index auf eine Spalte, die nur die Werte "ja" oder "nein" annehmen kann, ist relativ sinnlos, denn die Datenbank erhält hier fast keinerlei Vorteil durch einen Index, weil die möglichen Werte in der Spalte nicht sehr unterschiedlich sind.

      ein b-baum index ist nicht die einzige möglichkeit einer indizierung. andere dbms als zum beispiel mysql bieten da weitere möglichkeiten. und in diesem falle würde sich ein sogenannter bitmap index anbieten. dieser ist gerade für eine niedrige kardinalität ausgelegt.

      Ilja