Announcement

Collapse
No announcement yet.

Extra Server für Datenbank?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Extra Server für Datenbank?

    Hallo zusammen,

    es würde mich einfach mal pauschal interessieren, ab welchem Datenbank-Volumen und welchen Zugriffszahlen es sinnvoll ist in einen physikalisch eigenständigen Datenbankserver zu investieren. Auf was muss geachtet werden? Kann man die gleiche Performance vielleicht auch mit einem einzigen prozessorstarken Rechner erzielen? Hat jemand vielleicht Beispiele für mich?

    Habe konkret Probleme bei mehreren Zugriffen, weil meine Abfragen sehr lang sind (hatte schon mal wg. einem Performance-Problem gepostet -> Abfragen über 24 Felder in 13 Tabellen). Ist MySQL dem vielleicht nicht gewachsen? Was kann ich außer Indizies noch optimieren?
    Bin für alle Infos dankbar!

    Grüße,
    <i>nadine</i>

  • #2
    > Kann man die gleiche Performance vielleicht auch mit einem einzigen prozessorstarken Rechner erzielen?

    Oft ist eher ein zu geringer RAM eine Performance-Bremse. Vor allem dann wenn Indexe nicht im Speicher gehalten werden können sondern von Platte gelesen werden müssen.

    > Ist MySQL dem vielleicht nicht gewachsen?

    Bei MySQL ist mir (jedenfalls bei kleineren DB's) noch keine Signifikanter Unterschied zu "großen" DB's wie Oracle oder MS-SQL-Server aufgefallen

    > Was kann ich außer Indizies noch optimieren?

    Ja. Die diversen Buffer-Größen von MySQL. Evtl. hast Du zwar genügend Indexe aber der maximal von MySQL erlaubte RAM-Speicher ist zu gering definiert. Oracle oder MS-SQL Server machens es sich hier einfacher. Wenn nichts definiert ist holen sie wenn nötig erst mal alles verfügbare RAM. Hier ist Default-Mäßig MySQL auf Zurückhaltung eingestellt. Frag mich aber nicht an welcher Schraube (Buffer) du drehen mußt

    Comment


    • #3
      Ich bin der Ansicht, ein Datenbankserver im Echteinsatz sollte grundsätzlich immer ein eigener Rechner sein.
      Und ein Datenbankrechner kann auch nie zu schnell sein. allerdings ist hier die richtige Kombination entscheidend und nicht alleine die CPU-Leistung. Viel Hauptspeicher und die DB auf mehrere Platten verteilt ist meistens sehr leistungssteigernd. Es wäre aber kontraproduktiv ein Mehrprozessorsystem zu montieren und die Datenbank kann dann sowieso nur einen Prozessor verwenden.
      Ich muss aber dazusagen, das ist jetzt mal ganz allgemein, da ich selber nicht mit MySQL arbeite.
      Was dein Problem bei Zugriffen betrifft - ich kenne dieses Posting leider nicht, aber eines weiß ich ganz sicher - sollte das Problem am falschen Tabellenaufbau, fehlenden Indizes, verkehrtem Zugriffsplan oder schlecht formuliertem SQL liegen, dann kannst du das mit Hardware nicht wettmachen. Ich würde da mal versuchen, die Abfrage nochmals schrittweise von ganz klein weg aufzubauen, immer nur ein paar Felder, einen Join oder eine Tabelle mehr... um herauszufinden, wo die Bremsen sind. Und dann muss man sich das im Detail ansehen.<br>
      bye, Helmu

      Comment


      • #4
        Hallo Nadine,

        ich kann Helmut nur zustimmen!

        Indizes anlegen ist das eine, <b>brauchbare</b> Indizes das andere. Jeder Server hat so seine Eigenarten, wann er welche Indizes nicht benutzen kann. (Hauptsächlich im Zshg. mit LIKE '%blabla' oder Mehrspaltigen Indizes). Hier hilft nur ein Blick in den Ausführungsplan und entsprechende Korrektur (wenn möglich). Manchmal hilft auch schon ein etwas anders formuliertes SQL (WHERE A > 0 AND B = 4, statt WHERE B = 4 - wenn ein Mehrspaltiger Index auf A, B liegt und die Werte in A in jedem Fall > 0 sind)

        Die Abfrage von 13! Tabellen in einem Statement, mglws. mit mehreren OUTER JOIN halte ich von vornherein für eine Performancebremse. Da sollte man eher eher das Tabellendesign überdenken und kann damit mit Sicherheit mehr Performance rausholen als mit vetretbarem Aufwand durch geänderte Hardware.
        &lt;ergaenzung&gt;Ich weiß aus eigener Erfahrung, das man manchmal das Tabellendesign so nehmen muß, wie es ist. Hier helfen dann i.d.R. nur Kompromisslösungen. Wenn sich die zugrundeliegenden Daten bspw. nur (relativ) selten ändern, dann könnte man in einem Job, die benötigten Daten in einer separaten Tabelle zusammentragen. Zur Abfrage greift man dann nur auf diese Zwischentabelle zu und hat ein sehr schnelles Ergebnis (welches u.U. nich ganz up to date ist &lt;/ergaenzung&gt;

        Da MySQL keine Stored-Procedures verwendet halte ich dort auch einen Server mit schnellem (RAID) Plattensystem und genügend Hauptspeicher für sinnvoller als ein hochgetaktetes Mehrprozessorsystem.

        Gruß Fal
        Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

        Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

        Comment

        Working...
        X