Ankündigung

Einklappen
Keine Ankündigung bisher.

Update-Performance bei Tabellen mit vielen Einträgen

Einklappen

Neue Werbung 2019

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

  • #46
    VPh Ja, müssen sie. Denn der Tagesablauf im Spiel spiegelt nicht den realen Tagesablauf dar. Und jeder simulierte Tag im Spiel bedarf dieser Berechnungen.
    Somit bringt mir ein Cronjob an dieser Stelle gar nichts.

    Kommentar


    • #47
      Habe nochmal einige Test's gemacht.
      Mit 25.000 Datensätzen benötige ich ca. 900 ms für ein Update aller Datensätze nach dem Schema #38 auf einem (alten!) Entwicklungssystem.
      Mit ENGINE=MEMORY für die Updatetabelle reduziert sich die Zeit auf ca. 600 ms. Nun sind diese Ergebnisse nicht mit deiner (@Niko310391) Datenbankstruktur vergleichbar, eine genaue Analyse wo bei dir die Zeit bleibt dürfte sich trotzdem lohnen.

      Die Frage von VPh hätte ich so formuliert:
      Müssen diese Berechnungen denn immer ausgeführt werden, wenn ein User aktiv eine Seite aufruft? Aber wir kennen ja deine Abläufe nicht.

      Kommentar


      • #48
        Also es liegt wider Erwarten am SQL Statement:
        Calculation: 1,13715195656 sec
        SQL: 3,68900108337 sec

        In den Bereich Calculation fällt die Ermittlung der ganzen Effekte des Trainingstages und der Bereich SQL wertet die Arrays aus, schreibt sie per MultiInsert in eine temporäre Datenbank und aktualisiert die entsprechenden Tabellen dann auf Basis eben dieser.
        Daher bräuchte ich wirklich Hilfe im Bereich der SQL Optimierung.


        Die Frage von VPh habe ich schon verstanden. Aber ja, bei jedem vom User ausgelösten Tagesfortschritt (diesen kann er jederzeit in seinem Spielstand auslösen) müssen die Berechnungen neu ausgeführt werden.

        Kommentar


        • #49
          Dann hat dein Spiel ein Desingproblem.
          Bei vielen Spielen, wird halt alles im RAM gehalten und erst nach einer entweder vorab eingestellten Zeit oder beim verlassen des Spiels der Spielstand gespeichert.
          Bricht man die Spiele ab sind meist auch die Spielstände verloren. Das Betrifft insbesondere Wirtschaftssimulationen wo oft viele Berechnungen durchgeführt werden müssen. Ich beziehe mich jetzt auf Spiele die nicht online gespielt werden müssen, und shcon da ist das Problem offensichlich, den beim Speichern kann schon mal mehr als eine Sekunde vergehen.

          Du kannst dein Spiel ja im Hintergrund alle 10 Minuten per Cronjob speichern. Und hältst den Rest im RAM, dazu kannst du bei Mysql die Tabelle als Memory anlegen und überträgst dann nur von dieser Tabelle die Daten auf die Tabellle in der Festplatte.

          Du musst dir halt was überlegen.

          Eins steht aber ausser Frage das Schreiboperationen in eine DB teuer sind, das betrifft updates ebenso wie inserts. Kommen noch Indexe hinzu kann das richtig langsam werden, da ja bei jedem Insert oder update die ganzen Index-Tabellen auch aktualisiert werden müssen.
          Darüber solltest du dir im Klaren sein.

          Kommentar


          • #50
            Dann bitte ich dich, mir mal zu erklären, wie das klappen soll. Da bin ich leider überfragt.

            Es ist ja nunmal so, dass ich in jedem Menü auf Werte aus der Datenbank zugreife. Diese müssen dementsprechend auch aktuell bleiben. Also müssen auch die ganzen Berechnungen da reinlaufen, oder gibt es eine andere Möglichkeit?
            Vielleicht gibt es ja auch eine viel simplere Methode?!

            Ich hatte schonmal die Idee, zum Spielstart / beim Laden eines Spielstandes alle Daten einmalig in Arrays zu schreiben und dann während des Spiels immer nur die Werte aus dem Array zu aktualisieren und nur, wenn der User auf Speichern drückt, die Arrays wieder in die Datenbank zu schreiben. Geht sowas überhaupt? Wenn ja, kann mir jemand sagen, wie?

            Kommentar


            • #51
              Du willst ein Spiel programmieren, was meiner Meinung nach schon höchster Programmierlevel ist und fragst uns wie?
              Ein Mysql Tabelle im Ram anzulegen geht genauso wie sonst auch, lediglich die engine ist dann halt nicht innoDB sondern Memory. Lies im Handbuch den Rest nach.

              Du bleibst also bei Datanebanken hast halt nur 2. eine auf der Festplatte als "Archiv" und Sicherung und die memory für die Arbeitsumgebung.

              Arrays sind nicht persistent im Speicher. Die Memory DB aber schon.

              Kommentar


              • #52
                Welchen Vorteil bietet denn die Verwendung einer Memory Engine statt der InnoDB Engine? Sind die Zugriffe hier schneller bzw. auch die schreibenden Aktionen?
                Was ist denn mit meiner letzten Frage? Lässt sich sowas so in der Art auch umsetzen? Das würde das ganze ja um einiges schneller machen, da ich dann sogesehen keine Datenbank-Aktionen mehr habe außer beim Spielstart / Spielende.

                Kommentar


                • #53
                  Du stellst jetzt hier nicht so einfache Grundsatzfragen, oder?
                  Wie wäre es mit Nachdenken und evtl Bing, Google?

                  Kommentar


                  • #54
                    Zitat von Niko310391 Beitrag anzeigen
                    Ich hatte schonmal die Idee, zum Spielstart / beim Laden eines Spielstandes alle Daten einmalig in Arrays zu schreiben und dann während des Spiels immer nur die Werte aus dem Array zu aktualisieren und nur, wenn der User auf Speichern drückt, die Arrays wieder in die Datenbank zu schreiben. Geht sowas überhaupt? Wenn ja, kann mir jemand sagen, wie?
                    Wenn du ein Array genau so wieder brauchst wie es beim Speichern war dann brauchst du dieses auch nicht auseinander zu nehmen, sonder kannst es in einem Rutsch speichern. Das ist von Grundsatz mit so einer Klasse wie SQLiteObjectStore machbar. Die Klasse selbst habe ich jedoch nicht mit solch großen Arrays wie du sie hast getestet.
                    Edit: Wenn die Anzahl der Arrays überschaubar bleibt, können die serialisierten Daten auch direkt in Dateien geschrieben bzw. aus Dateien gelesen werden.



                    Zitat von Niko310391 Beitrag anzeigen
                    Welchen Vorteil bietet denn die Verwendung einer Memory Engine statt der InnoDB Engine? Sind die Zugriffe hier schneller bzw. auch die schreibenden Aktionen?
                    Die Frage wurde schon #47 beantwortet.
                    Mit 25.000 Datensätzen benötige ich ca. 900 ms für ein Update aller Datensätze nach dem Schema #38 auf einem (alten!) Entwicklungssystem.
                    Mit ENGINE=MEMORY für die Updatetabelle reduziert sich die Zeit auf ca. 600 ms.

                    Kommentar

                    Lädt...
                    X