Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] MySQL - Trennung von lesenden und schreibenden Queries

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] MySQL - Trennung von lesenden und schreibenden Queries

    Guten Morgen,

    nachdem ich hier schon eine Weile still und leise mitlese, wage ich mich jetzt mal selbst in den Haifischpool. Wenn ich mit meiner Frage im falschen Forum gelandet sein sollte, bitte ich um Entschuldigung - ich war mir nicht ganz sicher.

    Sache ist die: Ich befasse mich zur Zeit mit dem MVC-Prinzip, und obwohl ich im Bereich Design Pattern wohl noch nicht viel mehr bin als ein ambitionierter Newbie, nimmt die Sache langsam Formen an. Da ich lernen möchte, wie MVC von Grund auf funktioniert, habe ich mich gegen jegliche Frameworks entschieden und bastele ein "Spielprojekt" von Grund auf selber. Ich habe einen wirklich sehr guten Draht zu meinem Hoster, und der gute Mann bringt mich ab und an auf (manchmal reichlich schräge) Ideen. Gestern hat er mir erzählt, daß er für irgendein Verwaltungstool nicht nur eine, sondern zwei Datenbankverbindungen einsetzt - eine zu Server A (zum Schreiben) und eine zu Server B (zum Lesen). Replikation erfolgt automatisch, Konsistenz ist also gewährleistet.

    Seitdem grüble ich darüber, wie man sowas wohl in einem MVC-System umsetzt. Schreibende und lesende Queries zu trennen macht jetzt nicht so das Problem, aber wie instanziere ich am besten die DB-Objekte? Ich habe hin und her überlegt und bin bisher nur zu folgendem Schema gekommen:

    PHP-Code:
    $foo $registry->get('config')->settings['MYSQL_READ'];
    $readDB ReadingDatabase::getInstance($foo);
        
    $bar $registry->get('config')->settings['MYSQL_WRITE'];
    $writeDB WritingDatabase::getInstance($bar); 
    Der PHP-Highlighter scheint Backslashes zu fressen - ich habe die Namespaces einfach weggelassen.

    Wie falsch ist das jetzt? Und wenn's total daneben ist - wie geht's richtig? Ein paar Denkanstöße wären nett.

    Danke im Voraus.

  • #2
    Finde ich gar nicht falsch, ich mache es genauso, auch wenn es im Moment nur eine DB ist.

    Kommentar


    • #3
      Seitdem grüble ich darüber, wie man sowas wohl in einem MVC-System umsetzt. Schreibende und lesende Queries zu trennen macht jetzt nicht so das Problem, aber wie instanziere ich am besten die DB-Objekte?
      Das funktioniert IMHO nur mit einer weiteren Schicht für die Abfrage der Datenbanken. Hier bietet sich eine 3 tier architecture an, die MVC in der Präsentations-Schicht verwendet. Dann hast du den DB-Zugriff sauber gekapselt und musst dich innerhalb deines Controllers nicht darum kümmern.

      Alternativ kannst du MVC auch mit einem fat model ansatz betreiben und den DB-Zugriff darin kapseln.
      Viele Grüße,
      Dr.E.

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1. Think about software design [B]before[/B] you start to write code!
      2. Discuss and review it together with [B]experts[/B]!
      3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
      4. Write [I][B]clean and reusable[/B][/I] software only!
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      Kommentar


      • #4
        Vielleicht interesant:

        http://www.slideshare.net/kriswallsm...y-in-the-cloud

        Ab seite 23 wird beschrieben wie man doctrine 1 dazu bringen kann verschiedene datenbank-verbindungen zum lesen und schreiben zu nutzen, ist nicht nur symfony-spezifisch.
        [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
        | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

        Kommentar


        • #5
          Erstmal Danke für Eure Antworten!

          Es ist genau das eingetreten, was ich irgendwie erwartet hatte - drei Antworten, drei Meinungen.

          Zitat von xm22 Beitrag anzeigen
          Finde ich gar nicht falsch, ich mache es genauso, auch wenn es im Moment nur eine DB ist.
          Wenn es nur eine DB-Verbindung wäre, hätte ich damit auch keine Schmerzen. Aber zwei DB-Objekte zu registrieren kommt mir (aus zugegeben unerfindlichen Gründen) irgendwie unsauber vor.

          Zitat von dr.e. Beitrag anzeigen
          Das funktioniert IMHO nur mit einer weiteren Schicht für die Abfrage der Datenbanken. Hier bietet sich eine 3 tier architecture an, die MVC in der Präsentations-Schicht verwendet. Dann hast du den DB-Zugriff sauber gekapselt und musst dich innerhalb deines Controllers nicht darum kümmern.

          Alternativ kannst du MVC auch mit einem fat model ansatz betreiben und den DB-Zugriff darin kapseln.
          Ich verstehe das so: Die Verteilung auf den Lese- und den Schreibserver sollte innerhalb der DB-Klasse erfolgen, die wäre dann quasi ein Wrapper für zwei Instanzen von PDO (oder was auch immer). Alles, was also mit "SELECT" anfängt, schmeiße ich der ersten Instanz von PDO in den Rachen, alle anderen Queries bekomm Instanz Numero zwei serviert. Dabei tritt die ganze Konstruktion nach außen wie EIN Datenbank-Objekt auf und die Trennung erfolgt erst in der DB-Klasse - damit wäre diese problemlos austauschbar.
          Geht das in die richtige Richtung oder renne ich hier gegen die nächste Wand?

          Zitat von robo47 Beitrag anzeigen
          Vielleicht interesant:

          http://www.slideshare.net/kriswallsm...y-in-the-cloud

          Ab seite 23 wird beschrieben wie man doctrine 1 dazu bringen kann verschiedene datenbank-verbindungen zum lesen und schreiben zu nutzen, ist nicht nur symfony-spezifisch.
          Danke, aber damit gibt es gleich zwei Probleme. Erstens ist der Link tot, und zweitens will ich ja eben keinerlei Frameworks oder externe Libraries benutzen, sondern eben nur das, was PHP => 5.3.0 von Haus aus mitbringt. Das mag zwar sehr "zu Fuß" sein, aber mir geht es weniger darum mit möglichst wenig Aufwand eine Applikation zu produzieren als vielmehr um das grundlegende Verständnis - und da hat sich "learning augmented by doing" eben für mich als gute Methode erwiesen.

          Kommentar


          • #6
            irgendwie unsauber vor.
            Mir nicht
            Ich verstehe das so: Die Verteilung auf den Lese- und den Schreibserver sollte innerhalb der DB-Klasse erfolgen, die wäre dann quasi ein Wrapper für zwei Instanzen von PDO (oder was auch immer). Alles, was also mit "SELECT" anfängt, schmeiße ich der ersten Instanz von PDO in den Rachen, alle anderen Queries bekomm Instanz Numero zwei serviert.
            Das läuft auf das selbe hinaus. Es ist, wie Dr. E. schon angedeutet hat, eine Frage des Konzepts, an welcher Stelle Du die beiden Verbindungen wie vorhälst. Theoretisch könntest Du schreibende Zugriffe auch per Webservice woanders hin schicken, oder oder oder..

            Kommentar


            • #7
              Zitat von xm22 Beitrag anzeigen
              Mir nicht

              Das läuft auf das selbe hinaus. Es ist, wie Dr. E. schon angedeutet hat, eine Frage des Konzepts, an welcher Stelle Du die beiden Verbindungen wie vorhälst. Theoretisch könntest Du schreibende Zugriffe auch per Webservice woanders hin schicken, oder oder oder..
              Also wäre mein Ansatz mit den beiden PDO-Instanzen schonmal zumindest nicht falsch?

              Kommentar


              • #8
                Ja - Es ist Dir überlassen, wo Du die Wahl der Instanzen hinpackst. Optimal ist natürlich, wenn Die Applikation davon nichts mit bekommt.

                Kommentar


                • #9
                  Alles klar. Vielen Dank, Leute. Ich flag den Thread dann mal als erledigt.

                  Kommentar


                  • #10
                    Vielleicht kannst du dir auch was bei Doctrine abgucken, die trennen nicht nur Lesen und Schreiben, sonden verteilen das Lesen auch noch auf verschiedene Server in diesem Beispiel: http://www.doctrine-project.org/proj...ve-connections

                    Ist natürlich nur ein Bedienungsbeispiel, aber da lässt sich sicher tiefer reingehen.

                    Kommentar


                    • #11
                      Interessanter Hinweis. Das lege ich mal unter "Zukunftsmusik" ab, aber das klingt wirklich sehr brauchbar.

                      Danke für den Link!

                      Kommentar

                      Lädt...
                      X