Ankündigung

Einklappen
Keine Ankündigung bisher.

1 oder 2 Tabellen

Einklappen

Neue Werbung 2019

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

  • #16
    Zitat von VPh Beitrag anzeigen
    Genau diese Phase ist doch das Wartungsfenster.
    Während wir die Produktivumgebung noch einmal zur Abnahme testen [lassen], sind dort die normalen Sachbearbeiter vorerst nicht unterwegs; damit für diese im Falle eines Rollbacks keine unnötige Arbeit entsteht.
    Vielleicht reden wir aneinander vorbei. Unter einem "Wartungsfenster" verstehe ich eine Phase, in der kein "normaler" User die Anwendung benutzen kann. Und sowas ist bei vernünftiger Entwicklungs- und Test-Planung nicht notwendig.

    Wenn du allerdings "Wartungsfenster" so wie oben definierst, ist es sicher sinnvoll, sowas in Stunden zu legen, wo nicht viel schiefgehen kann. Aber bei vernünftiger Entwicklungs- und Testplanung passiert da eben auch nichts.

    Daß das manchmal auch alles ganz anders aussehen kann, ist mir klar. Aber es ist unsere Aufgabe, dafür zu sorgen, daß das "alle 100 Jahre einmal" passiert.

    Kommentar


    • #17
      Man muss hier vielleicht ein wenig schauen, dass man die Begriffe „Downtime“ und „Wartungsfenster“ übereinstimmend gebraucht. Ich kann hier leider keine Definition versuchen.

      Wenn man dedizierte und zugestandene Wartungsfenster hat, ist man mit Deployments halbwegs fein raus.

      Wenn man im laufenden Betrieb unterbrechungsfrei deployen muss, wird es unter Umständen sehr viel involvierter. (Und möglicherweise unwirtschaftlich, weil der Aufwand im Vergleich zu irgendeinem Wartungsfenster für die meisten Unternehmen keinen Sinn ergeben dürfte.)

      Aspekte, die sich auf den laufenden Betrieb beziehen, sind dann noch mal gänzlich andere Fragestellungen. Zum Beispiel: Was passiert, wenn die Festplatte des Datenbank-Servers ausfällt? Da geht es etwa um Redundanz. Das hat aber nichts mehr mit Deployment-Fragestellungen zu tun, die zum Beispiel DB-Migrationen umfassen.

      Kommentar


      • #18
        Zitat von marie123 Beitrag anzeigen
        Vielleicht reden wir aneinander vorbei. Unter einem "Wartungsfenster" verstehe ich eine Phase, in der kein "normaler" User die Anwendung benutzen kann. Und sowas ist bei vernünftiger Entwicklungs- und Test-Planung nicht notwendig.

        Wenn du allerdings "Wartungsfenster" so wie oben definierst, ist es sicher sinnvoll, sowas in Stunden zu legen, wo nicht viel schiefgehen kann. Aber bei vernünftiger Entwicklungs- und Testplanung passiert da eben auch nichts.

        Daß das manchmal auch alles ganz anders aussehen kann, ist mir klar. Aber es ist unsere Aufgabe, dafür zu sorgen, daß das "alle 100 Jahre einmal" passiert.
        Es gibt langlaufende Prozesse. Wenn du in einer Datenbank-Tabelle mit ein paar Millionen Einträgen eine Spaltendefinition änderst oder so, kann das schon mal eine Weile dauern.

        Man kann das Gesamt-Setup so auslegen, dass Anwender davon möglichst wenig mitbekommen, aber das ist ungleich schwieriger, als zu sagen: „Wir nehmen uns ein 30 Minuten Wartungsfenster.“

        Kommentar


        • #19
          Zitat von mermshaus Beitrag anzeigen

          Es gibt langlaufende Prozesse. Wenn du in einer Datenbank-Tabelle mit ein paar Millionen Einträgen eine Spaltendefinition änderst oder so, kann das schon mal eine Weile dauern.

          Man kann das Gesamt-Setup so auslegen, dass Anwender davon möglichst wenig mitbekommen, aber das ist ungleich schwieriger, als zu sagen: „Wir nehmen uns ein 30 Minuten Wartungsfenster.“
          Ein 30 Minuten Fenster, egal wir das betiteln, ist ja kein Problem. Aber ich ärgere mich einfach, wenn ich bspw. bei der Postbank mit "Wartungsfenstern" von 6 - 12 Std. konfrontiert werde.

          Das habe ich einfach anderes gelernt. Und das Prinzip lautet: Strenge Trennung von Entwicklung, Testen (mit gespiegelten Produktivdaten) und Produktivsetzen.

          Kommentar


          • #20
            Die werden sicherlich nicht am Livesystem entwickeln, aber wenn die Produktivdaten einen gewissen Umfang erreichen, ist das nicht mehr so einfach, sich die mal eben zu ziehen. (Datenschutzaspekte mal außen vor.) Das skaliert nicht. 3 MB überträgt man locker mal eben, 5 GB nicht mehr so.

            Wenn die Produktivdaten oder die Anfragen an das Produktivsystem einen gewissen Umfang erreichen, ist man mit gänzlich anderen Problemstellungen konfrontiert, weil man eben nicht mehr einfach so irgendwas im laufenden Betrieb anpassen kann, weil Operationen, die früher „keine“ Zeit brauchten, jetzt plötzlich Minuten oder Stunden oder noch länger brauchen. Allein wegen der Datenmenge.

            Das Hinzufügen einer Tabellenspalte läuft dann zum Beispiel mitunter so ab, dass man eine komplett neue Tabelle mit der entsprechenden Spalte erstellt und die Daten im Hintergrund rüberschiebt und im Code die neue Tabelle einträgt, sobald alles übertragen wurde. Man muss insbesondere darauf achten, dass man auch neue oder geänderte Einträge erwischt.

            Kommentar


            • #21
              Also die Probleme laufen etwas auseinander.
              Eine Bank Datenbank (postbank oder andere) gegen sicherlich in den Terrabyte Bereich, durchaus 2stellig. Hier sind Strukturänderungen u.U. zeitkritisch. Vielleicht nicht mal die Strukturänderung an sich, sondern eher die Datenmigration/-initialisierung. Damit haben wir eigentlich genau den Punkt, den JSON abfedern könnte.
              Nur würde man gerade bei einer Bank wahrscheinlich nicht mit adhoc Änderungen via JSON arbeiten.
              Ich sage einfach nur, es gibt irgendwo darunter den Bereich, wo man das machen kann, wo es Sinn macht und nutzbringend ist.
              Ein kleine, smarte Änderung mit oder vielmehr in einem JSON Feld, die dann wohl nicht in einem ebenfalls vorhandenen Perstistenzmodell Abbildung findet, sondern nur im Kontext einer speziellen Seite und ein paar speziellen JSON Daten existiert.

              Kommentar


              • #22
                WIe gesagt ist JSON kein Allheilmittel. Es wird auch Szenarien geben, wo man die JSON-Struktur migrieren muss.

                Ich bleibe bei meiner Meinung, dass NoSQL für dynamische Strukturen sinnvoll ist und relationale Datenbanken für statische Strukturen. Das eine gegen das andere tauschen macht nicht wirklich viel Sinn. Nur weil man eine statische Struktur als eine dynamische Struktur ausgibt, wird sie nicht wie durch Zauberhand wartbarer. Wenn da hunderte Business-Modelle, Services und APIs dranhängen, kann man nicht einfach so die Datenstruktur ändern, wie man will. Das muss ganzheitlich passieren.

                Kommentar


                • #23
                  Geht vielleicht so langsam auch Richtung: https://en.wikipedia.org/wiki/CAP_theorem

                  Manche Dinge sind einfach nicht einfach.

                  Kommentar


                  • #24
                    Zitat von hellbringer Beitrag anzeigen
                    WIe gesagt ist JSON kein Allheilmittel. ..Das muss ganzheitlich passieren.
                    Sagt ja niemand, dass es ein Allheilmittel ist. Im Gegenteil, es geht (mir) genau um die Differenzierung. "Ganzheitlich" ist eine Betrachtung und idealerweise auch die Lösung einer Aufgabe, aber das bedeutet nicht, das jedes Teilproblem mit dem gleichen Werkzeug erledigt wird. Oder wie war das Problem mit dem Hammer und dem Nagel(zitierst Du doch auch gern)?
                    Ich spreche schon gar nicht davon, dass ein NoSQL ein zweckmäßiger Ersatz für eine RDBMS ist. Ich mein, die sind grad mal ein paar Monate stolz darauf, dass sie endlich Transaktionen können.
                    Ein RDBMS, das neben seinen klassischen Features soetwas wie JSON oder XML integriert, bietet die Vorzüge beider Welten und das kann man sich zu Nutze machen.

                    Kommentar

                    Lädt...
                    X