Frage zu Caching und wie ich Objekte Speichern soll.

  • Hey,


    ich habe ein paar Fragen zur Datenstruktur. Erstmal mein Setup:


    Ich habe aktuell ein Rest-Backend für meine MongoDB Datenbank auf meinem Minecraft Server.


    Ich habe schon mehrmals überlegt auf SQL zu wechseln(Postgres) aber sehe aktuell nicht den Grund dafür.

    Wenn mich jemand überzeugen kann: gerne. Ich baue ja noch alles auf also schießt los 8)


    Die Fragen:


    Frage 1: Objekte Speichern:



    Ich habe ein Player Objekt was c.a so aussieht(hat noch ein bisschen mehr aber das juckt Grad nicht):


    JavaScript
    {
    "name": "lel",
    "uuid": "uuid",
    "adresses": {
    "first": "",
    "last": "",
    "list": []
    }
    }


    Jetzt möchte ich aber Einstellungen für die verschiedensten Systeme machen.


    Ich habe mir c.a so ein Objekt vorgestellt


    JavaScript
    {
    "namespace": "Lobby",
    "key": "slotSound",
    "value": true
    }

    Value dürfte dann alles sein aber ein Boolean repräsentiert das fürs erste relativ gut.


    Die Frage ist nun, ob ich diese Settings in das SpielerObjekt packen soll oder eher extern in einer Settings Collection. Diese Settings Objekte würden dann natürlich eine UUID für den Spieler haben :S


    Frage #2:


    Was sollte ich am besten Cachen? Das sowas wie Permissions zwischengespeichert werden sollte klar sein.


    Das Problem ist nun das ich nicht weiß, ob und wie ich SpielerObjekte Cachen soll da wir ja mehrere Unterserver haben welche zur gleichen Zeit Daten verarbeiten könnten.


    Wir haben zwar schon ein System zur Kommunikation zwischen den Servern jedoch finde ich es etwas kontraproduktiv bei jedem Spieler die ganze Zeit von Server zu Server diese Daten rumzusenden und zu speichern.

    Das Problem ist: Wenn ich sie nicht cache holt er sich jedes Mal das SpielerObjekt vom Backend, welches nicht das kleinste ist. Was sollte ich da machen?


    Ich würde gerne das Restkonzept behalten da wir viele Online Services machen werden, weswegen ich das alles Zentral haben möchte.


    Würde mich über Hilfe freuen.

    MFG

    RazerToaster

  • Zu Frage 2: Wichtig ist vielleicht die Überlegung, dass ein Spieler sich zu einer Zeit immer nur auf einem Server befindet (und dem Proxy, aber da werden höchstwahrscheinlich keine konkurrierenden Situationen auftreten, oder?). Das heißt, dass man beim Joinen des Spielers einmal die Daten laden und beim Verlassen die Daten in die Datenbank schreiben kann. Man muss dann nur sicherstellen, dass die Daten geschrieben wurden, bevor der Spieler auf den nächsten Server geschoben wird.

    MfG


    00110101 00110001 00110101 00111000 00110100 00110110 00110011 00110001 00110101 00111001 00110101 00110111 00110100 00110110 00110011 00110000 00110110 00110001 00110101 00110111 00110100 01000100 00110011 01000100 8o

  • Zu Frage 2: Wichtig ist vielleicht die Überlegung, dass ein Spieler sich zu einer Zeit immer nur auf einem Server befindet (und dem Proxy, aber da werden höchstwahrscheinlich keine konkurrierenden Situationen auftreten, oder?). Das heißt, dass man beim Joinen des Spielers einmal die Daten laden und beim Verlassen die Daten in die Datenbank schreiben kann. Man muss dann nur sicherstellen, dass die Daten geschrieben wurden, bevor der Spieler auf den nächsten Server geschoben wird.

    Man wird Coins weitergeben können. Das passiert auf den Bungee. Ich frage mich aber gerade auch was wohl passieren würde, wenn bei unserem kommenden Multibungeesystem zwei Leute gleichzeitig Bezahlen. Da steht ja kein Thread der noch einen anderen Task hat im weg. Dieses System habe ich zwar noch nicht angefangen und es ist auch nicht so wichtig aber trotzdem.


    Der Server kann ja während der Proxy die Coins verschickt die Coins durch Stats updaten oder so. Das ist das Problem dahinter.


    Und ich weiß nicht wie ich dafür sorgen soll das alle Server denselben Status haben da ich die Spielerdaten schon sehr früh abfragen muss(Permissions).


    Da lohnt es sich wahrscheinlich mehr die Daten zu schreiben, wenn sie verändert werden. Natürlich über einen ExecutorService. Aber das behebt nur ein Problem.

  • Uh und ich werde ja auch ein Webinterace haben da ich wenn ich wieder Schule habe(In Österreich sind die Schulen zu) nicht immer schnell Ingame handeln kann und weil es cool ist ^^


    Und ja das kann auch schreiben während der Spieler Ingame ist.

  • Ja, okay, dann muss man sich überlegen, welche Daten nur für einen Server zu einer Zeit relevant sind / nicht verändert werden, während der Spieler auf dem Server ist. Den Rest müsste man dann immer abfragen. Falls die Performance wirklich so kritisch ist, kann man ja auch noch einen schnellen Cache (z.B. Redis) dazwischenschalten.

    Und dann noch vielleicht eine Warnung: bevor ein Multiproxysystem wirklich praktikabel ist, braucht man mehrere tausend Spieler gleichzeitig auf dem Server, davor kann man das ganze noch wunderbar auf einem entsprechend dimensionierten Bungee laufen lassen. Also lieber klein anfangen und wenn es dann mal darauf zugeht wirklich einen ganzen Server mit einem Bungee ausreizen, DANN kann man sich darüber Gedanken machen. Davor ist das nur unnötiger Aufwand und zusätzliche Fehleranfälligkeit für keinen Vorteil.

    MfG


    00110101 00110001 00110101 00111000 00110100 00110110 00110011 00110001 00110101 00111001 00110101 00110111 00110100 00110110 00110011 00110000 00110110 00110001 00110101 00110111 00110100 01000100 00110011 01000100 8o

  • Ja, okay, dann muss man sich überlegen, welche Daten nur für einen Server zu einer Zeit relevant sind / nicht verändert werden, während der Spieler auf dem Server ist. Den Rest müsste man dann immer abfragen. Falls die Performance wirklich so kritisch ist, kann man ja auch noch einen schnellen Cache (z.B. Redis) dazwischenschalten.

    Und dann noch vielleicht eine Warnung: bevor ein Multiproxysystem wirklich praktikabel ist, braucht man mehrere tausend Spieler gleichzeitig auf dem Server, davor kann man das ganze noch wunderbar auf einem entsprechend dimensionierten Bungee laufen lassen. Also lieber klein anfangen und wenn es dann mal darauf zugeht wirklich einen ganzen Server mit einem Bungee ausreizen, DANN kann man sich darüber Gedanken machen. Davor ist das nur unnötiger Aufwand und zusätzliche Fehleranfälligkeit für keinen Vorteil.

    Es geht mir hauptsächlich ums ausprobieren ^^


    Ich denke das es in den meisten Fällen erstmal okay ist, wenn ich auf den Cache verzichte. Aber wird es nicht viel Datenstrom, wenn er jedes Mal ein großes JsonObjekt überträgt?

  • Es gibt in MongoDB, wie auch in relationalen DBs, eine Projektion. Damit kannst du einschränken, was übertragen werden soll.

    Wie intigriere ich sowas am besten mit meiner Rest-API? Wenn es hilft ich benutzte: https://nestjs.com/ dafür.


    Diese Implementation klingt schon mal nicht so schlecht. Ich habe ja glücklicherweise auch schon eine Implementation dafür gefunden nur die geänderten Variablen zu ändern.


    Dann werde ich wohl den Hauptcache entfernen :S