• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

PostgreSQL kompatibel zu MySQL?

binbash

binbash

Newbie
Grüzi miteinander,

mein Chef hatte eine Frage die ich so nicht beantworten konnte nun juckts mich und ich Frage mich ob wir unseren MySQL Datenbestand
eins zu eins auf PostgreSQL migrieren könnten ?
Ich bin da kein Fachmann wenn schon der Ansatz dumm ist dann Bitte ich um Entschuldigung für die Frage...falls es dennoch möglich ist habt Ihr mir ne
schöne Anleitung dafür ?

Danke
 
panamajo

panamajo

Guru
binbash schrieb:
mein Chef hatte eine Frage die ich so nicht beantworten konnte nun juckts mich und ich Frage mich ob wir unseren MySQL Datenbestand
eins zu eins auf PostgreSQL migrieren könnten ?
Zum Vergrößern anklicken....
IdR. nein. Unterschiedliche Features und Feldtypen (von ganz einfachen wie CHAR oder VARCHAR mal abgesehen).
binbash schrieb:
Ich bin da kein Fachmann wenn schon der Ansatz dumm ist dann Bitte ich um Entschuldigung für die Frage...
Zum Vergrößern anklicken....
Welche Vorteile verspricht ein Umzug auf PostgreSQL bzw. welche Nachteile habt ihr aktuell mit MySQL?
PostgreSQL skaliert besser bei mehreren CPUs und bietet ACID Unterstützung, MySQL ist bei MyISAM DBs idR. schneller.
 
OP
binbash

binbash

Newbie
Danke panamajo für deinen Post, die ganze Sache hat nun eine Nebenrolle bekommen...

Wir würden nun aber gerne einen weiteren Rechner dazu schalten um eine weitere Replikation des MySQL-Servers zu haben (mittlerweile wird der Master zeitversetzt auf zwei Slaves gesichert), damit man aus dieser Datenbank eine Nutzungs-Statistik der Seite errechnen kann (nur für interne Zwecke).
Wie man einen Slave anlegt ist mir bekannt aber gibt es irgendein howto wie man Statistiken aus der Datenbank auslesen bzw. errechnen kann?

Danke
 
Wizzzard

Wizzzard

Member
Was für Statistiken?

Ist damit eine Auswertung der realen Daten gemeint oder eine Statistik, die die Interna der Datenbank betreffen?

Ersteres macht man mit SQL-Statements. Da sollte jedes beliebige Buch zu SQL ausreichen, plus natürlich das Handbuch der Datenbank, um zu verifizieren, dass das angesprochene Feature im Buch auch in der Datenbank implementiert ist.
 
gurkfest

gurkfest

Newbie
myisam-tabellen sind echt klasse, keine transaktionen, keine fremdschlüssel und ein table lock bei updates, welche read-prozesse blockt.

innodb ist da etwas tauglicher; btw, ist mysql replikation nicht teil des enterprise cluster? der kostet doch, oder?

grundsätzlich ist es nicht so einfach db-systeme zu migrieren und die auswahl eines rdbms ist i.d.r. eine strategische entscheidung.

ich arbeite beruflich mit oracle, postgres und mysql; derzeit gerade ein mysql-projekt. leider fehlen da immer noch gescheite constraints, selbst bei innodb ist da nicht viel zu reissen.

wenn auf einem system massiv gelesen UND geschrieben wird und / oder viele daten enthalten sind, sind isam tabellen keine gute idee.

btw, innodb ist von oracle gekauft worden, mysql mittlerweile von sun. ich denke, strategisch sollte man neue OSS projekte man damit nicht mehr beginnen.

grüße
gurkfest
 
panamajo

panamajo

Guru
gurkfest schrieb:
und ein table lock bei updates, welche read-prozesse blockt.
Zum Vergrößern anklicken....
Davon habe ich noch nie was gemerkt, Quellen?

gurkfest schrieb:
wenn auf einem system massiv gelesen UND geschrieben wird und / oder viele daten enthalten sind, sind isam tabellen keine gute idee.
Zum Vergrößern anklicken....
Ersteres ist klar, allerdings haben andere RDBMs da auch ihre Probleme.
Bzgl. Gesamtgröße der DB: ab welcher Größe hast du welche Probleme bemerkt?
 
gurkfest

gurkfest

Newbie
panamajo schrieb:
gurkfest schrieb:
und ein table lock bei updates, welche read-prozesse blockt.
Zum Vergrößern anklicken....
Davon habe ich noch nie was gemerkt, Quellen?

7.3.1. Internal Locking Methods

[...]
MySQL uses table-level locking for MyISAM and MEMORY tables, page-level locking for BDB tables, and row-level locking for InnoDB tables.
[...]

gurkfest schrieb:
wenn auf einem system massiv gelesen UND geschrieben wird und / oder viele daten enthalten sind, sind isam tabellen keine gute idee.
Zum Vergrößern anklicken....
Ersteres ist klar, allerdings haben andere RDBMs da auch ihre Probleme.
Bzgl. Gesamtgröße der DB: ab welcher Größe hast du welche Probleme bemerkt?
Zum Vergrößern anklicken....

Die Probleme tauchen beim Altsystem meines Kunden auf, welches wir gerade neu schreiben und auf dessen wunsch auf innodb bringen. Btw, Oracle hat da kaum Schwierigkeiten, da Oracle von Hause aus mit Row-level Locking arbeitet und lesende Prozesse niemals von schreibenden blockiert werden (das gilt auch für mein präferierte OSS RDBM postgres).

Es handelt sich um ca 500000 Nutzdatensätzen von ca 300000 Usern, wobei jeder Klick auf einen Nutzdatensatz ein Update durchführt und bei einer Frequenz von ca. 400K hits am Tag den Cluster in die Bremse zwingt - dieses Analyseergebnis wurde allerdings nicht von mir ermittelt, sondern war der Grund meines Projekts ;-)

Ich mache nächste Woche erste Lasttests mit größerem Volumen und innodb-Tabellen. Wenn es Dich interessiert, poste ich das Ergebnis hier noch einmal.

Grüße
Marcus
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben