Datenbank größe... PO

    • mikeandmore10
      mikeandmore10
      Bronze
      Dabei seit: 27.03.2007 Beiträge: 315
      Hallo ihr lieben,
      hab gerade mal gerechnet.
      Ich mine Momentan ca. 15.000 Hände pro Tag. Wenn ich dass nun ein Jahr mach hab ich ja knapp 4.5 MIO Häne in der Datenbank.... wann wird es denn nun zuviel, bzw. schafft das PO noch vernünftig? bzw. SQL???
      Ich mein in 3 Jahren sind das weit über 10 Mio Hände.....!!!!

      Gruß
  • 5 Antworten
    • Risinhigh
      Risinhigh
      Bronze
      Dabei seit: 07.08.2007 Beiträge: 1.461
      Ich kenn die Grenzen nun nicht, weiß nichtmal ob es überhaupt welche gibt (außer die Festplattengröße), aber ich hab hier in PT ne 4 Mio Hände DB (insgesamt) "gehabt".

      Das einzige wirkliche Problem welches du bekommen wirst je größer deine Datenbank ist, desto weniger Spaß machen je nach Rechnerleistung die HUDs, da dort immer die gesamte DB durchforstet werden muß um zu den entsprechenden Einträgen zu gelangen. Kann man sich ja rec ht leicht vorstellen das das immer länger dauert je gößer die DB wird.

      Jedoch denke ich mal nicht das du in 3 Jahren noch auf dem gleichen Limit spielen wirst, was die Sache deutlich erleichtert ;)

      Ich bin hingegangen und habe meine Datenbank dann irgendwann mal gesplittet und die Minings von meiner Main DB getrennt.

      Will heißen ich habe meine Main-DB wo alle Hände reinkommen wo ich am Tisch war, um davon auch Auswertungen in der Gesamtheit mit PokerEV oder Pokergrapher zu ziehen. Dort sind auch alle Limits und alle Seiten welche ich gespielt habe drin vereint.

      Dann habe ich zusätzlich für jedes Limit eine eigene Datenbank wo die Minings reinkommen.

      Ich spiele SSS, bin auf NL50 angekommen, meine Datenbankstruktur sieht also wie folgt aus:

      Main-DB
      PP_Mining NL10
      PP_Mining NL25
      PP_Mining NL50

      und aktuell mine ich schon NL100 auf PP ein wenig mit wofür es auch eine eigene DB gibt, da ich nun vor habe demnächst nach Everest zu wechseln wird es dort dann auch eine eigene DB geben für Mininghände auch separat für die Limits sollte ich in der Zeit eins aufsteigen.

      Auf diese Weise hälst du deine einzelnen Datenbanken schön klein und PA HUD funktioniert deutlich flüssiger, da weniger Daten durchforstet werden müssen, wenn man dann hingeht und die Datenbanken welche nicht benötigt werden deselektiert und nur die auswählt welche man benötigt. Aktuell um in meinem Beispiel zu bleiben ist meine NL10 und NL25 DB deselektiert, da ich sie nicht brauche... also werden die auch nicht durchforstet ;)

      Wie das nun mit PO aussieht kann ich dir nicht sagen, ich spreche da nun nur aus der Erfahrung mit PT und PA, kann mir aber kaum vorstellen das das bei PO anders sein sollte :D

      Hoffe dir geholfen zu haben...

      lg
      risinhigh
    • mikeandmore10
      mikeandmore10
      Bronze
      Dabei seit: 27.03.2007 Beiträge: 315
      Ja ich denke schon, dass du geholfen hast !!

      Diese teilen in eiegen und fremde Games... geht dass relativ einfach ?
      Ich könnte mir vorstellen zum Bsp. geminte Hände die Älter sind wie 6 MOnate immer wieder zu löschen oder so?

      Gruß
    • Risinhigh
      Risinhigh
      Bronze
      Dabei seit: 07.08.2007 Beiträge: 1.461
      Original von mikeandmore10
      Diese teilen in eiegen und fremde Games... geht dass relativ einfach ?
      ich bin einfach von anfang an hingegangen und habe die Minings immer separat abgespeichert und die HHs aus dem PP eigenen Ordner separat eingelesen in die Main-DB.

      anschließend dann auch sortiert abgespeichert. Bei PP ist das ja recht einfach da die Ordner schon das Datum als Namen haben, wie das bei anderen Anbietern aussieht weiß ich leider nicht.

      Das gleiche mache ich mit meinen Minings die werden auch mit Datum beschriftet.

      In PA kannst du auswählen das nur die letzten X Hände benutzt werden sollen, hab diese Funktion jedoch noch nicht benutzt, kann dazu also nix sagen, ob das die Performancebelastung runterschraubt, ich vermute aber mal eher im Gegenteil, weil er dann ja auch noch mehr arbeit hat es zu filtern.

      Was aber sicherlich kein Problem sein sollte ist die Daten nach einer Zeit aus der DB auch zu löschen. Bei PT ist das ohne weiteres möglich unter utilities -> database maintenance and options. Dort kann man dann alle Sessions auswählen welche ein älteres Datum haben und diese dann löschen.

      Ob das mit PO auch so einfach geht kann ich dir nicht sagen, aber ich vermute es einfach mal bzw ich hoffe es für dich *G*
      Aber ich denke mal bis das wichtig ist solltest du eh PT haben...
    • mikeandmore10
      mikeandmore10
      Bronze
      Dabei seit: 27.03.2007 Beiträge: 315
      ja ich speichere SIe auch seperat ab.... dass heißt du machst dir von zeit zu zeit einfach neue Datenbanken indem du wieder alle HH neu einliest...?? Dass kann ja bei eineigen Tasuend noch machbar sein, aber was ist mit eineigen hunderttausend??
      SOllte ich denn auf PT umsteigen wollen? Gibt es denn da Vorteile? auser dass was wir gerade bescheiebn? Ich dachte die seien ziemlich gleich !
    • Ryukyu
      Ryukyu
      Bronze
      Dabei seit: 11.07.2007 Beiträge: 201
      Ich habe zum Thema Datenbanken und Datenbankstruktur auch ein paar Fragen. Habe zwar die Suchfunktion bemüht, aber nicht wirklich gute Infos gefunden.

      Wie sieht das denn mit der Aktualität von Daten aus? Wie frisch sollten die Daten sein? Macht es Sinn, sich drei Monate alte Daten einzulesen? Kann ich mir ehrlich gesagt nicht vorstellen, dafür ändert sich gerade am Anfang noch zu sehr die Spielweise und außerdem wechseln ja die Gegner recht häufig. Wieviele Hände brauche ich in etwa, um wirklich eine anständige Datenbasis zu haben?

      Ich wollte eigentlich pro Limit für jeden Monat eine Datenbank anlegen und dann im PokerAce die Daten mit den zwei aktuellsten Dateien verwenden. Geht es sehr auf die Performance, wenn ich Daten aus zwei Datenbanken ziehe? Wenn das möglich ist, kann ich so die Datenbank auf Dauer in einer überschaubaren Größe halten und habe keine zu veralteten Daten.