Announcement

Collapse
No announcement yet.

Skalierbarkeit i/o performance?

Collapse
X
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Skalierbarkeit i/o performance?

    Hallo zusammen,

    oder besser guten Morgen zusammen? Ich habe es bisher nicht nötig gehabt mich Datenbanken auseinander zu setzen, die auf mehr als einem PC/Server laufen. Dies wird sich nun aber ändern und somit stellen sich ein paar Fragen, bzw. insbesondere erstmal eine. Für meinen Anwendungsfall (Datawarehousing mit viel Dateninput und wenig Usern) kommt man ab irgendeinem Punkt mit schnellen SSD's nicht mehr weiter. Nun stellt sich die mir die Frage kann man die i/o Leistung weiter herauf skalieren in dem man sein dbms (oracle 11g2) in einer VM installiert und diese auf einem server-cluster laufen lässt? Vorteil dabei wäre, dass die Infrastruktur (Server-Cluser) bei einigen unserer Kunden schon vorhanden wäre und/oder auch leicht erweitert werden kann. Oder macht dies ausschließlich Sinn über die oracle RAC funktionen?!
    kann jemand hierzu etwas sagen/beitragen? Eine kurze Begründung für an abgegebenes Statement wäre schön.

    Danke + Gruß.

    PS: wenn wir zu einem Ergebnis kommen: gilt das auch für andere dbms (postgres o.ä.)?
    Tags: None
  • #2
    Mit VM kannst Du keine I/O Skalieren ebensowenig mit RAC, denn hier skalierst Du nur die CPUs.

    Du musst die Datafiles per RAID strippen bzw. die datafiles explizit auf unterschiedlichen Platten ablegen.

    Allerdings würde mich interessieren, was das für Anwendungsfälle sind. Wenn Du schon SSDs verwendest und es immer noch nicht schnell genug ist.
    Wir laden hier auf "normalen" Platten 12GB an Daten in unter 10 Minuten in die Datenbank (Raid 5 im SAN, OCFS2 Filesystem)

    Man sollte sich eher mal den Ladeprozess ansehen. Wie sieht der denn aus?

    Dim
    Zitat Tom Kyte:
    I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

    Comment

    • #3
      Hallo dimitri,

      danke für die Antwort(en). Dass man mit dem RAC nur die CPU power skaliert war mir nicht bewusst. Bei ner VM wusste ich es einfach nicht. Aber du nennst ja ganz klar alternative Lösungen.
      Momentan ist es nicht so, dass es auf der "letzten Rille" läuft. Es handelt sich um ein Server der wissenschaftliche Messdaten die von Meßgeräten gesendet werden aufzeichnet. Diese können dann mit einer (Web-)Applikation ausgewertet werden - allerdings sind das im Regel fall maximal 1-10 User gleichzeitig, die mit Auswertungen arbeiten. Problem ist, dass die Anzahl der Meßgeräte, die Daten schicken, als auch die Datenmenge, die jedes Meßgerät schickt je nach Aufgabenanforderung hier vor Ort immer weiter steigen kann. Irgendwann wird es dann halt knapp - tut es aber aktuell noch nicht.
      Zudem möchte ich ein möglichst großen Overhead in i/o Leistung haben, damit a) die Auswertung flüssig läuft und b) die Meßgeräte Daten nachsenden können. Gemeint ist, wenn das Meßgerät mal keine Verbindung zum Server hat cached es die Daten und sendet die sobald wieder eine Verbindung da ist. Wenn das nun zeitgleich mit 50 Meßgeräten passiert und diese 50 dann Daten nachsenden wollen kommt es natürlich zu einem hohen Aufkommen, was möglichst gut abgearbeitet werden soll.

      Was wäre also das maximum was machbar wäre? SSDs im RAID, davon ggf. mehrere und dann ein Tablesapce anlegen welches datafiles nutzt, die auf die verschiedenen raid's verteilt sind? Nur mal so rein theoretisch!?

      Dank + Grüße

      PS: Und ja ... Querys der Auswertungsanwendung wurden gründlichst optimiert

      PPS: Es gibt Messgeräte die senden mehr als 2mbit/s ... wenn dann 50-100 im Einsatz sind, kommt schon ne menge zusammen. Zumal die 24/7 laufen.

      Comment

      • #4
        PPS: Es gibt Messgeräte die senden mehr als 2mbit/s ... wenn dann 50-100 im Einsatz sind, kommt schon ne menge zusammen. Zumal die 24/7 laufen.
        Das sind grade mal ~25 MByte pro Sekunde aufgeteilt auf 50-100 Sessions. So tragisch ist das nicht, dass sollte auch ein heutiger PC mit flotter Platte hinbekommen, wenn das Ladeprogramm richtig gemacht wurde.

        Eine SSD Lösung etc. ist hier m.M. nach gar nicht nötig, wenn die Datenbank, die Instance und die Anwendung ok sind.

        Dim
        Zitat Tom Kyte:
        I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

        Comment

        • #5
          Originally posted by dimitri View Post
          Das sind grade mal ~25 MByte pro Sekunde aufgeteilt auf 50-100 Sessions. So tragisch ist das nicht, dass sollte auch ein heutiger PC mit flotter Platte hinbekommen, wenn das Ladeprogramm richtig gemacht wurde.

          Eine SSD Lösung etc. ist hier m.M. nach gar nicht nötig, wenn die Datenbank, die Instance und die Anwendung ok sind.

          Dim
          Achso - ich hatte es nicht erwähnt. Es läuft ein Daemon der die Daten entgegen nimmt und nur dieser trägt die Daten ein. Und ja das läuft auf Problemlos auf einer Platte. Problematisch wird es dann wenn Jobs anlaufen die aus den gesammelten Daten Statistikwerte berechnen und diese in entsprechende andere Tables schreiben (die aber momentan noch auf der selben Platte liegen, kann man ja auch erstmal noch ändern). Dann machen die Plattenköpfe deutlich mehr Seeks, was bekanntlich bremst.

          Das sequenzielle schreiben von 25mb/s ist auch kein Problem. Aber Oracle schribt ja auch das Log nebenher und ich will die Dauer einer Transaktion (also die Inserts, die von dem Daemon kommen) auch nicht beliebig groß machen (momentan 2-3s).

          Gruß

          Comment

          • #6
            Das sequenzielle schreiben von 25mb/s ist auch kein Problem. Aber Oracle schribt ja auch das Log nebenher und ich will die Dauer einer Transaktion (also die Inserts, die von dem Daemon kommen) auch nicht beliebig groß machen (momentan 2-3s).
            Inserts verursachen nicht viele REDO und UNDO Einträge. Indices kommen evtl. noch hinzu.
            Wenn Du das ganze trennen möchtest, dann pack die "Sammeltabelle" in einen eigenen Tablespace und das zugehörige Datafile legst Du auf eine extra Platte (z.B. eine kleine schnelle SSD).

            UNDO und REDO sollten dann auch auf der SSD liegen.

            Dim
            Zitat Tom Kyte:
            I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

            Comment

            • #7
              Kann es nicht eher sein, dass der Flaschenhals hier liegt:
              Originally posted by stede View Post
              Problematisch wird es dann wenn Jobs anlaufen die aus den gesammelten Daten Statistikwerte berechnen und diese in entsprechende andere Tables schreiben
              Ich denke die Limitierung kommt nicht vom I/O, sondern von der Berechnung. Wenn die DB alle Werte einer Spalte addieren muss, dann muss nun mal die ganze Tabelle gelesen werden. Das ist etwas anderes als wenn sequenziell am Ende Daten hinzugefügt werden.

              Gruss

              Comment

              • #8
                Wernfired das beeinträchtigt sich wenn es auf einer HDD ist natürlich gegenseitig negativ.

                Bin erstmal weg - das Wochenende unterwegs. Lese mal nach wie ich UNDO/REDO Logs eines Tables in einem bestimmten Ort ablegen kann.

                Danke soweit für eure Hilfe + Anregungen!

                Grüße

                Comment

                Previous template Next
                Working...
                X