nicht angemeldet
DB-System für gr. Tabellen
Hallo,
manche Tabellen von unserem Server haben bereits 20GB und werden jährlich um ca. 5GB anwachsen.
Zur Zeit benutzen wir MySQL mit MyISAM.
Jetzt frag ich mich aber welche DB vielleicht viel besser für uns wäre, denn folgende Probleme treten zur Zeit bereits auf:
- Wenn man ein Feld ändert/hinzufügt/löscht, dann dauert dies ewig, genauso wie mit einem Index.
- Backup soll incrementell oder ein hotbackup sein, was wir leider eben mit MyISAM nicht haben
Bei diesen gr. Tabellen sollen lediglich folgende Aktionen gemacht werden:
- SELECT aber in der WHERE-CLAUSEL steht dann nur der PRIMARY KEY
- DELETE über den PRIMARY KEY
- INSERT
- TRIGGER bzw. foreign-key-constraint, damit in Untertabellen die zugehörigen Daten auch rausgelöscht werden
Gibt es für meine Anforderungen vielleicht schon die perfekte storage engine in MySQL, oder eignet sich hier vielleicht ein anderes DB-System viel besser wie zB:
- PostgreSQL
- Oracle
- Firebird
- MSSQL
Für eure Antworten bedanke ich mich jetzt schon sehr herzlich.
lg
Christoph
-
Hi,
20 GB an Daten?
Beinhalten diese 20 GB auch BLOB-Daten?
Wie sieht denn die Verteilung dieser 20 GB über alle Tabellen hinweg aus?
Wie de/normalisiert sind denn die Daten?
Welchen Lebenszyklus/Lebensdauer haben die Daten, sprich liessen sich ältere Daten mit Erstellungsdatum < 2006 einfach in eine andere Tabelle auslagern? (Horizontale Partitionierung)
Hmmm, SELECT, DELETE, INSERT ...? Fehlt nur noch UPDATE, dann wäre die Runde komplett. :) Mal im Ernst, finde heraus, welche Tabellen statischer als andere sind und bringe das mit den Tabellengrössen in Verbindung.
Wenn ihr nur SELECTs mit dem PK als Suchargument macht, wie kommt ihr dann auf diesen PK Wert? Evt besteht dort bereits ausreichend Optimierungspotential.
Und Trigger sind ganz ganz dolle "evil" ... (nur mal so nebenbei)
Geht es euch rein um die Grösse und die Probleme, inkrementelle Sicherungen nicht machen zu können und habt ihr Leistungseinbrüche im täglichen Betrieb?
Sicher, dass es rein an der Grösse hängt, nicht eventuell an konkurrierenden Zugriffen und Locks auf der Datensatzebene?
Übrigens kann man auch mit anderen "richtigeren" ;) Datenbanksystemen total mässige Systeme zusammenkleistern, die schon bei 3 GB an Daten im Mehrbenutzerzugriff ins Schlucken kommmen. (Und selbst die kann man auch noch für ne knapp 7stellige Summe pro jahr verticken.)
Ich hoffe, ich konnte dir ein paar Anhaltspunkte für deine weitere tiefergehende Analyse liefern.
Gut NAcht, Frank
-
yo,
mehrere DBMS sollte in der lage sein, deinen genannten anforderungen zu genügen, bei Oracle und MSSQL weiß ich es, Postgre und mysql sollten es auch können. was du machen willst sind letztlich "Basics".
ich behaupte mal, selbst unter mysql sind bestimmt noch erhebliche tuning-maßnahmen möglich, aber dazu müsste man genau wissen, was ihr macht und wo die probleme liegen.
Wichtiger finde ich andere kriterien, in welchen maße braucht ihr ausfallsicherheit, habt ihr ein 24/7 system und vor allem wer besitzt das know-how, das entsprechende DBMS auch zu administrieren oder muss dazu erst das wissen erlangt, bzw. eingekauft werden ?
Ilja
-
Hi Christoph
- Wenn man ein Feld ändert/hinzufügt/löscht, dann dauert dies ewig, genauso wie mit einem Index.
Hier solltest du mit Low-Level-Tuning viel rausholen können: Indem du die Datenbank auf mehrere Festplatten verteilst. Die Swap-Datei vom Betriebssystem sollte auf keinen Fall auf derselben Platte liegen. Auch Daten und Indexe/Logs lassen sich gut verteilen. Nur so als Anregung.
Gruss
Tom