pfad zur datenbank

Hallo,

ich würde gerne die eine und andere Tabelle ins tmpfs legen, um Zugriffe darauf zu beschleudigen. Hierzu will ich einfach einen Link der Tabelle ins tmpfs legen, was ja auch soweit funktioniert.

Ich würde das setzen des Links mit einem Installationsskript gerne automatisieren, nur weiß ich nicht genau, wie ich da vorgehen soll.

Der Pfad zur Tabelle ist ja so aufgebaut:

/var/lib/postgresql/8.1/main/base/[database_id]/[table_id]

um den link zu setzen zu können, muss ich ja zuerst mal den pfad ermitteln, welcher oben steht.

table_id kann ich anhand der Tabelle pg_class der Spalte “relfilenode” entnehmen.

Nur woher bekomme ich die “database_id” her?

Habe mir nunmal gedacht, ich nehme einfach die table_id und durchsuche alle Datenbanken, wo diese vorkommt, so müsste ich eig. die database_id ermitteln können. Nur sind die table_ids wirklich über alle datenbanken eindeutig?

mfg

Ich würde dir stattdessen vorschlagen, dich mit Tablespaces zu beschäftigen.

Jedoch muss ich dich an dieser Stelle auch warnen: es kann gut passieren, das deine Datenbank nach einem Crash gar nicht mehr startet weil die Dateien im Tmpfs verschwunden sind - diese jedoch für Crash Recovery benötigt werden.

Gibt es also keine gscheide Möglichkeit, eine Datenbank in den Ram zu legen?

Unter MySql gibts ja eine eigene Engine.

PostgreSQL legt Wert auf die Sicherheit deiner Daten. Von daher gibt es hier keine Engines, die Daten mal eben verschwinden lassen, keine für den/das RAM und auch keine Blackhole Engine. Sorry.
Finde dich damit ab, das die Datensicherheit in PostgreSQL wesentlich strenger gehandhabt wird als in Mysql.

Im übrigen: wenn du Daten hast die sowieso verschwinden können, wozu brauchst du noch eine SQL Datenbank? Was genau ist also das Problem, das du lösen möchtest?

Du könntest deine Daten in eine sqlite-Datenbank mirrorn, die kannst du aus eben diesen Performace-Gründen auch ins RAM werfen. Änderungen etc musst du halt nachführen. Die Funktionalitäten und Strukturen, die du brauchst könntest du über ein Abstractionlayer wie z.B. sqlalchemy (für Python) abbilden, so das die RAM-Version das gleiche macht wie das Orginal.

Gruß Uwe

Ich habe bestimmte Tabellen, auf dennen ständig geschrieben und gelesen wird. Würde der Server mal ausfallen, so könnte man die Tabelle wieder rekunstruieren anhand von anderen Tabellen.

was denn zu langsam ist, bei der arbeit auf einer normalen HDD?

ich meine wenn du die DB in den RAM verlagern willst, kann sie ja “soo gross” nicht sein …

vielleicht prüfst du mal nach, was denn “zu langsam” ist … fehlen indizes - werden sie nicht benutzt (kommt ja nich selten vor bei PG wenn man mal wieder diesen unsinnigen operator-klassen wahnsinn ignoriert hat)

Derzeit habe ich noch keine Performenceprobleme, es sind aber etwa in der Sekunde 20 Update Abfragen, welche jeweils ~40 Zeilen updaten.

Ich befürchte aber, dass die Updates pro Sekunde und Zeilenanzahl weiterhin ansteigen wird, da meine Bsucherzahlen größer werden…

Also da würde ich mir mal nicht so den Kopf drueber machen, ob das nun im RAM oder auf HDD ablaeuft. Ich denke mal du machst dir da bei deinen IO-Last Überlegungen zuviel gedanken an der falschen Stelle. Bei UPDATEs haettest du sowieso die betroffenen rows im RAM (Platten-cache) - beim commit wird die Table ja erstmal erweitert (wegen der Transaktion) da muss PG auch nicht in unbekannten gegenden rumkratzen.

Du könntest z.B. überlegen welche Indizes du brauchst - die ja auch aktualisiert werden - und oft bei solchen überlegungen übersehen werden - oder ob du die in einen anderen Tablespace auf einer andern HDD platzierst (dann kann der mehr oder minder parallel geschrieben werden), wobei ich denke, dass die 20 * paar kByte nicht wirklich eine Größenordnung für gaengige HW darstellen.

Meißt lassen sich Probleme lahmender DBs auf Modellierungsfehler zurückführen. Ein anderes Nadelöhr ist das häufig unterschätzte Kommunikations-Aufkommen zwischen einem Client und der DB … da kann man sich auch ueberlegen wie man moeglichst wenig Abfragen braucht - oder ob man z.B. deine Updates von 20 Zeilen nicht in einem Update unterbringen kann … ein UPDATE WHERE id IN VALUES(id1, id2, id3 … usw) ist wesentlich effizienter als 20 mal das update für nicht benachbarte ids aufzurufen.

Der AK hat da bestimmt auch noch viele Ideen die er aber ungern verrät - der S*ck :slight_smile:

Hallo, danke für deine Antwort. Werde demnach die Tabellen doch auf der HDD liegen lassen :-).

Gibts irgendwo ein gscheides Howto über Tablespaces? Und wie kann ich eigentlich ein Index auf einer anderen Platte plazieren?

Was genau zählst du da?

Naja die PG doku findest du ja online - google einfach zu einem beliebigen thema - wie “Postgres Tablespace” irgendeiner der ersten links auf der seite zeigt auf ne PG doku irgendeiner version

PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: CREATE TABLESPACE

im grunde ist ein tablespace ja nix weiter als dass du dem PG server sagst wo er die daten der DBs speichern darf …

so einem tablespace gibst also nen namen und nen ort auf irgendeiner HDD wo der PG-dienst bzw. deamon schreibrechte hat (der prozess laeuft ja unter nem bestimmten system “user”)

CREATE TABLESPACE tablespacename [ OWNER username ] LOCATION 'directory’und dann kannst du den tabellen bzw. indizes beim CREATE TABLE oder CREATE INDEX in welchem deiner tablespaces die gespeichert werden sollen

also z.B. CREATE TABLE stress (
) TABLESPACE tablespacename;

Für den Index das gleiche in grün.

Ich denke es macht ohnehin sinn tabellen und indizes so zu erzeugen - auch wenn die tablespaces erstmal auf die gleiche platte zeigen … es sollte spaeter dann naemlich einfach reichen per backup und restore die geschichten zu aendern … die namen sind ja schon zugewiesen … aber man kann die daten so entsprechen umplatzieren. Es gibt ja auch noch andere gruende sowas zu machen - du koenntest z.B. so daten auf verschluesselte partitionen lagern und und und …