Suche schnelle Speichermöglichkeit

[KahPee]

Hallo,
ich habe vor ein Programm zu schreiben wo ich mehrere Milliarden Einträge in einer Datenbank speichern muss. Ich möchte die Gewinnwahrscheinlichkeiten für alle möglichen Hände beim Pokern (Hold'em) errechnen lassen (ja ich weiß, dass das nen weilchen dauern wird :P); und anschließend in eine Datenbank einspeichern, damit diese Wahrscheinlichkeiten am Ende möglichst schnell wieder ausgelesen werden können.

Ich bin lernfähiger Fortgeschrittener und nutze TurboDelphi (was aber Delphi sehr sehr sehr ähnlich ist). Was ich suche ist eine Datenbank oder irgendeine andere Speichermöglichkeit, die schnelles Schreiben und vorallem schnelles Auslesen ermöglicht!
Bisher habe ich nur in .ini-Dateien informationen abgespeichert, aber ich befürchte, dass das nicht gerade die schnellste Variante ist.

Gerade bei so großen Datenmengen wäre interessannt worauf ich außerdem noch achten muss um ein möglichst schnelles Ergebnis zu erzielen (wenn ich dann irgendwann die Wahl einer Datenbank getroffen habe).

Schon mal vielen Dank im vorraus!

KahPee

[Mithrandir]

Zitat:

Zitat von KahPee

TurboDelphi (was aber Delphi sehr sehr sehr ähnlich ist).

Süß. :mrgreen:
Oder meinst du TurboPascal?

Als Datenbanken fallen mir Firebird, SQLite und MYSQL ein..

[s.h.a.r.k]

Warum du Datenbank nutzen *musst*: diese sind (meist) auf Schnelligkeit hin optimiert und haben gegenüber Dateibasieren Formaten (XML und INI) viele Vorteile: Schnelligkeit, einfache Suche (SQL), Austauschbarkeit etc.

PS: TurboDelphi ist Delphi, aber nur eine etwas abgespeckte Version :zwinker:

[KahPee]

Okay.
Welche Datenbank ist für soetwas denn am besten geeignet? Welche Unterschiede (Vor- und Nachteile) gibt es bei den verschiedenen Datenbanken? Die Schnelligkeit ist bei so großen Mengen bei dem Projekt für mich von erster Bedeutung ;).
Ziemlich sicher werde ich das Programm am Anfang auf mehreren PC laufenlassen, sodass jeder PC teile des ganzen errechnet. Interessant wäre auch wie schnell man am ende diese Ergebnisse zusammenführen kann in einer einzigen Datei. Copy/Paste wäre natürlich perfekt, wobei ich auch bereit bin nen Programm zu programmieren, dass den Copy/Paste prozess dann übernimmt ;).

KahPee

[himitsu]

Milliarden?

alle möglichen Kombinationen pro Spieler:
52*51*50*49*48 + 52*51*50*49 + 52*51*50 = 318.505.200 (Millionen)

alle möglichen Kombination über ein ganzes Blatt
3,4*10^62 ... ich befürchte da reicht deine Festplatte nicht aus


PS: TurboDelphi = eingeschränktes Delphi 2006

[Basilikum]

ob das wirklich klappen kann ? du sprichst von "einigen" Milliarden Einträgen... nehmen wir mal an, es seien 3 Milliarden Einträge: jeder Eintrag sprich Record in der DB wird wohl ca. 40 Bytes umfassen (Wahrscheinlichkeit -> Float, irgendwie müssen die "Hände" abgebildet werden, Meta-Daten, Index, etc...) -> das gibt dann bereits 120 GB Daten...
ob das ein oder auch drei oder fünf banale Heim-PCs bewältigen können ?!?
da ist dann nix mit kurz Copy'n'Paste... :-)

[KahPee]

So hab das ganze nochmal durchgerechnet, mir war schon klar, dass da größere Datenmengen anfallen. Nach verschiedenen Optimierungen müssen am Ende ca. 3*(10^9) Einträge abgebildet werden. Alle müssen eine Wahrscheinlichkeitsnummer die vier- fünfstellig ist haben (eine nachkommastelle, kann aber als byte oder ähnliches abgebildet werdern) und einen String (2-14 Zeichen) enthalten. Also max. ca. 20 byte pro datensatz. Teilweise weniger.

Das würde dann 56 GB an Daten machen (nen bissl mehr). Die Berechnungen sollen nicht nur auf HeimPCs laufen ^^ in der Hinsicht wird sowohl Masse als auch Klasse ins Rennen geworfen ;).

Bleibt natürlich die Frage wie schnell man bei der eingabe einer Hand den entsprechnenden Datensatz in der DB findet

mfg KahPee

[Delphi-Laie]

Das ganze soll doch nicht etwa auch noch in Echtzeit (also die, über die man als Pokerspieler für seine Entscheidungen gewöhnlicherweise verfügt) reagieren und einem die Entscheidungen beeinflussen oder gar abnehmen?

Wenn ich diese Datenmengen lese, so garantiere ich, daß das für die derzeitig verfügbare, erschwingliche Heimelektronik auch unter dem Einsatz von 64 Bit, Terabyte an HDD-, etlichen Gigabyte an Hauptspeicherkapazität, einigen Megahertz an Prozessortakt und mehreren Prozessoren oder wenigstens Prozessorkernen dennoch eine solch gewaltige Herausforderung sein wird, daß diese nur äußerst zäh reagieren wird.

[rollstuhlfahrer]

ich persönlich würde MySQL und nen 64Bit-System mit mehr als 4 GB Hauptspeicher nehmen. Je mehr Hauptspeicher die Kiste hat, desto schneller kann die auch die ganzen Einträge verarbeiten. Mal grob gerechnet wird das aber SEHR teuer. 56GB sind ein ganzes Stückchen. Da wirst du nicht alles im Hauptspeicher halten KÖNNEN. Und bei der Suche wirst du dir auch noch was einfallen lassen müssen. Ich hab keine Vorstellung wie das gehen soll. Höchstens 32 boolean-Werte in denen dann das Blatt drin steht. Die boolean-Werte lassen sich aber auch in einem 32-Bit Integer speichern, welcher genauso groß ist, aber die DB nicht so stark belastet.

Bernhard

PS: Ich lass dich ganz einfach mal machen.

EDIT: oups: Poker geht ja nicht mit 32 Karten. Das sind ein paar mehr.

[Luckie]

Warum so großen Datenmengen vorhalten? Das Errechnen sollte nicht viel länger dauern als das Suchen in einer so großen Datenbank. Man sollte sich wohl eher Gedanken machen, wie man die Karten, die man auf der Hand hat möglichst effizient eingibt.

[KahPee]

Das Auslesen sollte in Echtzeit sein, allerdings habe ich bei den Datenmengen angefangen umzudenken, da selbst bei hohem Rechneraufwand das nen weilchen länger dauert als gedacht ;). Ich werde die verschiedenen Möglichkeiten kategorisieren, d.h. die Menge wird deutlich kleiner und es wird auch nicht mehr alles ausgerechnet.

Teile der Werte habe ich schon als Tabelle vorliegen (Excel/OOo). Die Frage ist weiterhin was eine möglichst schnelle Datenbank ist. Jetzt würde auch interessant sein ob man da möglichst elegant Werte aus Excel- oder OOoCalc tabellen übernehmen kann. Gibt es da etwas praktisches mit MySQL?

Wie lange sucht man in einer solchen Datenbank (deutlich kleiner als 56GB eher unter 1GB)? Bzw. welche effizienten Suchmethoden gibt es um ein Suche in der jeweiligen DB schnell zu gestalten?

mfg KahPee

[rollstuhlfahrer]

a) Gibt's was praktisches an MySQL: Die Verbreitung! Ansonsten fühlt sich MySQL rasant schnell an.
b) Die Suche ist immer am schnellsten, wenn du stehts nur nach 1 oder 2 Zahlen suchst. Wenn du die Bläter in 2 Integer bekommst, sollte das reichen. Ansonsten kannst du auch 52-boolean Felder machen.

Bernhard

[Bernhard Geyer]

Reicht es denn nich schon die vorhandenen Statistikdaten wie hier oder hier hier mit ein bischen Mathematik?

[Luckie]

Könnte man eventuell mit Bitmasken arbeiten? Dann reichen zwei Integerfelder aus. Eins für die Bitmaske der Hand und eins für die Wahrscheinlichkeit. Nachkommastellen halte ich für Blödsinn bei der Wahrscheinlichkeit.

[mirage228]

Zitat:

Zitat von Luckie

Eins für die Bitmaske der Hand und eins für die Wahrscheinlichkeit. Nachkommastellen halte ich für Blödsinn bei der Wahrscheinlichkeit.

Also für mich sind Wahrscheinlichkeiten Kommazahlen zwischen 0 und 1, zumindest wenn man nah an der Mathematik bleiben möchte... ;-)

[sx2008]

Ich denke man kann das am Besten zur Laufzeit berechnen.
Du hast 3 Karten auf der Hand und möchtest deine Siegchancen berechnen wenn du 2 weitere Karten erhalten hat.
Also sind noch (52 - 3) * (52 - 4) = 2352 Kombinationen zu bewerten.
Man braucht eine Schleife über diese Kombinationen und eine Bewertungsfunktion.
Die Bewertungsfunktion bekommt 5 Karten als Input und liefert als Ergebnis ob es sich um
eine Einzelkarte, ein Paar, Drilling, Strasse, Flush, Full House, Vierling, Straight Flush oder Royal Flush handelt.
In einem Array mit 10 Einträgen werden nun die Stückzahlen aufsummiert.
Die Gesamtsumme dieses Arrays muss wieder 2352 ergeben.
Am Ende lassen sich die Stückzahlen in Prozente umrechnen.

Ich schätze, dass ein Programm diese Arbeit in weniger als 1 Sekunde erledigen kann.
Wenn man nur 2 Karten auf der Hand hat, muss man 117600 Kombinationen berechnen;
nicht gerade wenig, aber Computer sind ja schnell.

[himitsu]

52 Karten + 12 Bit (0..4095) für die Wahrscheinlichkeit = 64 Bit aka 2 Integer

Das ließe sich sogar sehr gut in einer einfachen Binärdatei vorhalten
und da man diese Liste eh sortiert abspeichert, würde man dort auch sehr schnell suchen können ... also theoretsich wäre man so sogar schneller als eine DB.

[KahPee]

Also ich rede hier im Moment von Hold'em. Wenn der Flop schon liegt bedeutet dass: 2 Karten auf der Hand sind bekannt und 3 sind offen. Im Extremfall sind 9 Gegner noch dabei. Jetzt müssen alle Kombinationen mit den restlichen 47 Karten durchgespielt werden (Turn, River sowie die Gegnerhände) [ca. 2,3*10^28 Berechnungen (teils schon optimiert)]. Selbst nach optimierung bleiben da zuviele Berechnungen um es zur Laufzeit zu machen.

Aber ich werde, das ganze anders aufziehen ;). Bleibt die Frage was ob es ei MysQL oder anderen Datenbanken eine schnelle gibt, die einen Import aus Excel/OOo ermöglicht.

mfg KahPee

P.S.: Das Problem bei der erstmals angesprochenen Variante ist nicht die Speicherplatzgröße sondern die benötigte Rechenzeit! Die obige Nummer zeigt die Berechnungen die bei einer hand nötig sind!

[himitsu]

Der Excelimport sollte notfalls kein Problem darstellen.
Von Delphi aus, kann man auf Excel zugreifen und da man ja auch zugriff auf die DB oder Sonstwas hat, kann man natürlich auch beliebig hin- und hertransferieren.

[Reinhard Kern]

Zitat:

Zitat von Delphi-Laie

Wenn ich diese Datenmengen lese, so garantiere ich, daß das für die derzeitig verfügbare, erschwingliche Heimelektronik auch unter dem Einsatz von 64 Bit, Terabyte an HDD-, etlichen Gigabyte an Hauptspeicherkapazität, einigen Megahertz an Prozessortakt und mehreren Prozessoren oder wenigstens Prozessorkernen dennoch eine solch gewaltige Herausforderung sein wird, daß diese nur äußerst zäh reagieren wird.

Alles relativ - ich habe in den letzten Tagen eine Pressemitteilung gelesen über eine 48 Core-Maschine (6 x 4 + HT) mit 64 GB Ram. Zum Schnäppchenpreis bei "das ist MEIN Laden" gibts die allerdings nicht, und man darf auch nicht den Zeitaufwand unterschätzen, einen 64 GB-Speicher vollzuladen.

Gruss Reinhard

[Luckie]

Zitat:

Zitat von mirage228

Also für mich sind Wahrscheinlichkeiten Kommazahlen zwischen 0 und 1, zumindest wenn man nah an der Mathematik bleiben möchte... ;-)

Das ist schon klar. Nur wird man die Wahrscheinlichkeit in der Regel in Prozent angeben und dann sind Nachkommastellen nicht mehr sehr aussagekräftig.

Zitat:

Zitat von KahPee

Also ich rede hier im Moment von Hold'em. Wenn der Flop schon liegt bedeutet dass: 2 Karten auf der Hand sind bekannt und 3 sind offen. Im Extremfall sind 9 Gegner noch dabei. Jetzt müssen alle Kombinationen mit den restlichen 47 Karten durchgespielt werden (Turn, River sowie die Gegnerhände) [ca. 2,3*10^28 Berechnungen (teils schon optimiert)]. Selbst nach optimierung bleiben da zuviele Berechnungen um es zur Laufzeit zu machen.

Klingt nach einem perfekten Problem für eine Parallelrechner. ;)

[ChEeTaH]

Für den Fall, dass du Student bist, darfst du Rechenleistung vom Leibniz Rechenzentrum in München-Erding benutzen :zwinker: . Daten:
http://www.lrz-muenchen.de/services/...are/index.html
:mrgreen:

[generic]

Kennst du das hier:
http://www.pokerwahrscheinlichkeiten...-berechnen.php

[Maximus]

Ein ganz guten Weg das Problem zu lösen wird hier http://www.pst.ifi.lmu.de/~hammer/poker/handeval.html beschrieben.

Außerdem findest du dort eine Textdatei die schon Wahrscheinlichkeiten für alle Möglichkeiten beinhaltet. Diese kannst du ja zu Beginn deines Programms in ein Array einlesen. Damitsolltest du die Wahrscheinlichkeit für einzelne Kombination sehr schnell wieder auslesen können.

[ChEeTaH]

evtl hilft dir dieses Open-Source PokerSpiel mit Bot weiter: http://sourceforge.net/projects/pokerth/files/ :thumb: