MySQL-Datenbank im Arbeitsspeicher bereithalten

[Eddie]

Hallo allerseits,

ich habe keine Ahnung, ob sowas moeglich ist, darum einfach mal die Frage an die Spezialisten: ich entwickle gerade eine DB-Tabelle, die praktisch keine schreibenden sondern sehr viele lesende Zugriffe haben wird. Dafuer ist sie um die 500 MB gross (zumindest als CSV) und umfasst ca. 6 Millionen Datensätze.
Geht das also irgendwie, dass ich meiner DB sage, sie soll den ganzen Schmu konstant im schnelleren Arbeitsspeicher halten? Erst bei Aenderungen muesste ich den dann neu laden...

Keine Ahnung, wie sowas gehen soll, klingt aber grossartig :-)
Achja, Ziel-DB ist MySQL, die Datenbank für Arme...

Danke für eure Hilfe,
Eddie

[Eddie]

Nochmal ich :-)

Angeblich soll ja Postgres bei Suchanfragen sehr schnell sein, zumindest hat mir das jemand geraten. Nur bekomme ich wohl auf einem ManagedServer kaum eine andere Datenbank zum Laufen. Oder???

Eddie

[J.P.]

Weiss zwar keine Antwort,
aber mich würde interessieren was das für Inhalt ist.

Klingt nach dmoz ?

J.P.

[Eddie]

Hallo J.P.,

aber mich würde interessieren was das für Inhalt ist.

Klingt nach dmoz ?

Ne, es geht um Geodaten, also viele Orte in aller Welt :-)

Eddie

[Christoph Schnauß]

hallo Eddie,

Geht das also irgendwie, dass ich meiner DB sage, sie soll den ganzen Schmu konstant im schnelleren Arbeitsspeicher halten?

Ja, das geht "irgendwie". Allerdings ist die Ausgangsinformation, die du lieferst, extrem dürftig. Und ob nun MySQL oder PostgreSQL ist dabei ziemlich wurscht.

Grüße aus Berlin

Christoph S.

[Eddie]

Hallo Christoph,

Allerdings ist die Ausgangsinformation, die du lieferst, extrem dürftig.

Ok, was brauchst du?
Ich versuch mal zu liefern, was ich hab, keine Ahnung, ob ich es schaffe, spezifisch genug zu werden (mit meiner Ahnung von der Materie...). Also:

• 6.000.000 Datensätze
• in einer Tabelle (die anderen Tabellen sind wesentlich kleiner)
• sehr viele lesende Zugriffe auf diese Tabelle, ggf. schreibende Zugriffe auf andere Tabellen
• PHP/MySQL
• 1GB Arbeitsspeicher (koennte aber auch mehr werden, kostet halt Geld...)

Was musst du sonst noch wissen?

Danke dir,
Eddie

[Christoph Schnauß]

hi,

Ok, was brauchst du?

Och, ich brauche eine bezahlte Telefonrechnung *g*

Im Ernst: es geht nicht darum, was _ich_ brauche, sondern darum, was _du_ an Info zur Bewältigung deines Problems benötigst.

• 6.000.000 Datensätze

Das liest sich zwar beeindruckend, ist aber wenig aussagekräftig. Es kommt weniger auf die Zahl der Datensätze an, als vielmehr darauf, wie "groß" sie sind und was der Server in welchem Zeitintervall an Speicher zur Verfügung stellen kann.

• in einer Tabelle (die anderen Tabellen sind wesentlich kleiner)
• sehr viele lesende Zugriffe auf diese Tabelle, ggf. schreibende Zugriffe auf andere Tabellen

Das dürften vernachlässigbare Faktoren sein.

• PHP/MySQL

PHP stellt vermutlich den Auslesemechanismus, und MySQL ist nur die Datenbank. Soweit ich weiß, ist das genauso "schnell" wie PostgreSQL

• 1GB Arbeitsspeicher (koennte aber auch mehr werden, kostet halt Geld...)

Das ist unter Umständen der limitierende Faktor.

Was musst du sonst noch wissen?

Nix, es ist ja _dein_ Problem und nicht meines ;-)
Aber, um nochmal deine Frage aus dem OP aufzugreifen:

Geht das also irgendwie, dass ich meiner DB sage, sie soll den ganzen Schmu konstant im schnelleren Arbeitsspeicher halten? Erst bei Aenderungen muesste ich den dann neu laden...

Was hast du denn bisher probiert? Es ist deutlich leichter, eventuelle Fehlermeldungen zu kommentieren, als Mutmaßungen darüber abzugeben, ob irgendwas funktionieren könnte oder nicht. Also mach doch mal, probiere aus - und wenn du auf die Nase fällst, hast du wenigstens aussagekräftige Fehlermeldungen, mit deren Hilfe man dir _wesentlich_ genauer sagen kann, wo du herumschrauben solltest. _Prinzipiell_ solltest du keine Probleme bekommen, aber schon der arme alte Bert Brecht schrieb einmal in sein Tagebuch: "Prinzipien halten sich am Leben durch ihre Verletzung".

Grüße aus Berlin

Christoph S.

[Vinzenz Mai]

Hallo Eddie,

Ich versuch mal zu liefern, was ich hab, keine Ahnung, ob ich es schaffe, spezifisch genug zu werden (mit meiner Ahnung von der Materie...). Also:

• 6.000.000 Datensätze
• in einer Tabelle (die anderen Tabellen sind wesentlich kleiner)
• sehr viele lesende Zugriffe auf diese Tabelle, ggf. schreibende Zugriffe auf andere Tabellen

• PHP/MySQL

Du suchst die Memory Storage Engine.

Freundliche Grüße

Vinzenz

[Eddie]

Du suchst die Memory Storage Engine.

Perfekt, das war genau die Antwort, die ich gesucht habe!

Danke dir, Vinzenz!
Eddie

[Sven Rautenberg]

Moin!

Du suchst die Memory Storage Engine.
Perfekt, das war genau die Antwort, die ich gesucht habe!

Das glaube ich nicht unbedingt. Oder was ist für dich eine Tabelle wert, die beim Beenden von MySQL gelöscht wird?

- Sven Rautenberg

[Sven Rautenberg]

Moin!

ich habe keine Ahnung, ob sowas moeglich ist, darum einfach mal die Frage an die Spezialisten: ich entwickle gerade eine DB-Tabelle, die praktisch keine schreibenden sondern sehr viele lesende Zugriffe haben wird. Dafuer ist sie um die 500 MB gross (zumindest als CSV) und umfasst ca. 6 Millionen Datensätze.
Geht das also irgendwie, dass ich meiner DB sage, sie soll den ganzen Schmu konstant im schnelleren Arbeitsspeicher halten? Erst bei Aenderungen muesste ich den dann neu laden...

Optimiere nicht an Problemen, die du noch gar nicht hast!

Es ist derzeit deine _Vermutung_, dass die Speicherhaltung im RAM schneller sein soll.

Aber wenn du die OpenGeoDB inklusive Index & Co. immer komplett im Speicher hälst, fehlt der dir für den restlichen Betrieb des Servers. Das Betriebssystem wird dann unter Umständen RAM auslagern - und damit wäre für dich nichts gewonnen, weil die Datenbank dann doch wieder von Festplatte liest. Nur eben mit der u.U. schlechten "Optimierung" durch die RAM-Verwaltung des OS, nicht durch die datenbankoptimierte Verwaltung von MySQL.

Wenn dein Projekt soweit fertig ist, dass du tatsächlich Geschwindigkeitsprobleme _hast_ - dann solltest du das Problem analysieren und Gegenmaßnahmen ergreifen. Aber so pauschal einfach mal ein halbes Gigabyte Datenbank im Speicher halten (und das bei jedem Neustart von MySQL erneut befüllen müssen) ist keine Lösung, die man "nur mal so" anwenden sollte. Denn MySQL hält ja sowieso diverse Informationen im RAM parat.

- Sven Rautenberg

[Eddie]

Hallo Sven,

seh ich eigentlich genauso, ich wollte nur vorab meine Moeglichkeiten abklaeren, genau fuer den Fall, dass es irgendwann eng wird. Klar, wenn ich soviel Traffic habe, muss sowieso ein anderer Server mit mehr RAM her. Aber es ist schon gut, zu wissen, dass es Moeglichkeiten gibt, das Ganze zu optimieren - wie kompliziert das dann wird, sei heute mal noch dahingestellt.

Danke dir,
Eddie