"We are back" « oc.at

[MySQL] MyIsam oder InnoDB?

Bogus 30.11.2009 - 14:00 8446 27 Thread rating
Posts

Bogus

C64 Generation
Avatar
Registered: Mar 2006
Location: Graz
Posts: 3171
hi

die generellen unterschiede sind mir bereits bekannt.
nutze derzeit inno-db. dadurch sind die tabelle mit den bestellpositionen und die mit den produktstammdaten 2-3 mal so groß als es mit myisam der fall wäre.

die programmierung an sich ist 'as simple as possible'. ich nutze keine transaktionen oder locking.
folglich könnte ich doch einfach auf myisam umstellen, oder?

bei myisam lese ich immer von nachteilen bei datensicherheit/integrität. wirkt sich das auch auf mich aus, wenn ich nur selects, inserts und updates schiebe?

soll heissen: liegt es an der art und weise wie innodb queries abarbeitet (also ohne mein zutun), oder bringt innodb nur vorteile wenn man auch speziell mit transaktionen oder dergleichen arbeitet?

TIA

Neo1010

.
Registered: May 2003
Location: -
Posts: 1212
soweit ich weiß unterstützt myisam keine foreign keys

Bogus

C64 Generation
Avatar
Registered: Mar 2006
Location: Graz
Posts: 3171
hab kurz nachgeschlagen was du mit 'foreign keys' meinen könntest.

muss mich dazu outen: hab nix studiert oder gelernt bezüglich programmierung. hab mit 10 jahren mit basic und 'hallo welt' begonnen. rest ist learning by doing. seit ich mit datenbanken arbeite (seinerzeit access) habe ich immer eindeutige keys benutzt. so auch bisher immer mit myisam. diese sind auf autoincrement gestellt und unique. damit sollte doch jeder datensatz eindeutig sein.

oder hab ich das jetzt wieder falsch verstanden?

(ps: am entwicklungsserver läuft die tabelle komplett als myisam. nur online ist es [durch zufall] innodb)

ill

...
Avatar
Registered: Nov 2003
Location: Salzburg
Posts: 2060
myisam überprüft keine verweise auf andere tables (eben über foreign keys)

als beispiel:

Ich habe hier eine Tabelle Abteilung und eine Tabelle Arbeiter. Jeder Arbeiter ist explizit einer Abteilung zugeteilt.

Wenn ich nun über InnoDB einen Datensatz in Arbeiter schreibe, welcher auf einen Datensatz in Abteilung verweist, welcher noch nicht existiert, verweigert InnoDB das.
MyIsam macht das ohne Mucken (was natürlich im Endeffekt zu Fehlern führt)

Ich persönlich arbeite so gut wie nur mit InnoDB und ich weiß jetzt auch nicht genau, wie du deine DB-Struktur dann wirklich verwenden willst?

ica

hmm
Avatar
Registered: Jul 2002
Location: Graz
Posts: 9823
Zitat von ill
Ich persönlich arbeite so gut wie nur mit InnoDB und ich weiß jetzt auch nicht genau, wie du deine DB-Struktur dann wirklich verwenden willst?

jup, ist zu empfehlen. außer für sonderfälle wo du full-text search brauchst. oder du verwendest mysql plugins die das für dich machen.

EG

thinking with portals
Avatar
Registered: May 2004
Location: 11**
Posts: 3918
Wenn die Datenbankgröße wirklich problematisch sein sollte, kannst du Foreign Keys auch mit der Implementierung abbilden...is halt nicht sauber!

Was genau hat dich zu diesem Thread bewogen? Dauern die Backups zu lange?

kleinerChemiker

Here to stay
Avatar
Registered: Feb 2002
Location: Wien
Posts: 4307
Wenn man die InnoDB Features nicht nutzt, ist MyISAM wohl besser. Soll auch beim lesen flotter sein.

Bogus

C64 Generation
Avatar
Registered: Mar 2006
Location: Graz
Posts: 3171
unter access hies das ganze 'verknüpfungen', oder? damit hatte ich seinerzeit schon gearbeitet. unter mysql erledige ich diese verbindungen mittels php. wenn man sich ne saubere struktur (+ benennung) angewöhnt hat, gibts da keine troubles.

was mich zu der überlegung bewegt: innodb braucht mehr platz und ist langsamer. wenn ich die features davon nicht nutze ist es somit unnötig und myisam die bessere wahl.

bisher war mir die größe der db immer egal. aktuell gibts aber 25000 kunden (das geht ja noch) und 800000 bestellpositionen. letztere db hat jetzt schon 130mb. ist bei updates und größeren db-operationen halt nervig....


full-text search ist nice. hab mir aber schon lange ne simple funktion geschrieben die das ganze mittels normalem query erledigt. konnte mich bisher nicht dazu bewegen die gesamte struktur meines 'grundpaketes für php projekte' neu zu coden........

EG

thinking with portals
Avatar
Registered: May 2004
Location: 11**
Posts: 3918
Naja das ist ja schon halbwegs ordentlich für eine "kleine" Datenbank.

innoDB wär sicher schneller und würd sich dementsprechen rentieren, wenn du die Relationsbeziehungen aus der Anwendung raus in die Datenbank ziehst.

Wie du sagst "du machst es mit php"...würd da auf jedenfall rechtzeitig an ein entsprechendes Datenbankkonzept denken. k.A. wie schnell die DB wirklich wächst, aber es kann sehrgut sein, dass du da schnell an die Grenzen des Systems stößt. Dann brauchst unnötigerweise zusätzliche Maschinen/Cluster/Load-Balancing.

Ich überzeichne das bewusst etwas. Bei so vielen Verknüpfungen wird die DB sicher spürbar schneller wenn du foreign keys verwendest.

Bogus

C64 Generation
Avatar
Registered: Mar 2006
Location: Graz
Posts: 3171
hatte schon weitaus größere datenbanken (vor 5-10 jahren auf vergleichsweise schwachen single-core maschinen). ohne probleme.

allerdings behalf ich mir damals damit das jedes jahr eine neue archiv-table für alte einträge angelegt wurde.

mein problem ist halt das ich nur noch nebenberuflich code (für vitamin-b kunden) und von daher nicht mehr am laufenden bin :(
das letzte was ich mir noch antun werde is ajax. dann bin ich - nach ca 20 jahren 'programmieren' und neue sprachen lernen - voll.

PS: ich schaf's ja nicht mal vom veralteten homesite endlich auf ultraedit oder ähnliches umzusteigen.....
Bearbeitet von Bogus am 01.12.2009, 13:38

EG

thinking with portals
Avatar
Registered: May 2004
Location: 11**
Posts: 3918
Hm...also Ajax ist ja vereinfacht gesagt nur, wenn man mit javascript teile einer Seite dynamisch nachläd....keine große Hexerei und geht ganz leicht. Wennst php und a bissl js kannst hast da schon gewonnen.

Aber das hat eh nix mit der DB zu tun.
Wenn du Performanceprobleme hast bzw. durch das Wachstum der DB erwartest, würd ich auf jedenfall das Konzept an sich überdenken. Irgendwann explodiert die Komplexität der Datenbank und dann kannst alles neu designen. Hier auf jedenfall mehr auf Skalierbarkeit achten.

Solang es so läuft wie du sagst kannst auch probieren die Datenbank testweise mal in einer Entwicklungsumgebung laufen zu lassen.

Zukunft hat das System aber nicht. Soll heißen du wirst entweder mal deine nebenberufliche Tätigkeit an einen Profi abgeben, oder der Kunde wird in dickere Hardware investieren müssen.

jives

And the science gets done
Avatar
Registered: Sep 2001
Location: Baden
Posts: 3548
Sehr interessanter Thread, vor allem für Programmierer im Selbststudium :)

Zitat von EvilGohan
Hier auf jedenfall mehr auf Skalierbarkeit achten.
Und wie macht man das? Einfach InnoDB mit foreign keys erscheint mir doch zu einfach, oder? ;) Gibt es da gewisse Grundregeln, mit denen man schon mal sehr gut fährt, oder ist das von Fall zu Fall eigens zu überlegen? Hat dazu jemand vielleicht empfehlenswerte Artikel im Netz, oder auch "normale" Literatur?

Edit:
Noch zwei Fragen:
Inwiefern bringen Referenzen die in der DB implementiert werden Geschwindigkeitsvorteile oder eine bessere Skalierbarkeit?

Wenn man mal das Wikipedia-Beispiel (http://en.wikipedia.org/wiki/Foreign_key#Example) hernimmt:Welche Vorteile bringt das REFERENCES-Keyword? Bekomm ich dann bei einem SELECT die entsprechenden Daten aus der refenzierten Tabelle gleich mit (JOIN-mäßig)? Oder bezieht sich das nur auf Updates udgl.?
Bearbeitet von jives am 01.12.2009, 14:51

EG

thinking with portals
Avatar
Registered: May 2004
Location: 11**
Posts: 3918
Ein wesentliches Problem von PHP-"Anwendungen" ist ja eigendlich die schlechte Skalierbarkeit, weil php so etwas eigendlich nicht vorsieht.

Hab da erst unlängst mit einem Admin von fotoplace.at ein interessantes Gespräch geführen: die machens so, dass sie ihre Webserver mit DNS loadbalancen und für ihre Datenbanken postgreSQL einsetzen - was ja wesentlich mächtiger ist als mysql.
Klar diese Anwendung ist wesentlich komplexer, aber hier bräuchte man jedenfalls mehr Informationen über die konkrete Anwendung von Bogus.

Wie schauts mit der Performance jetzt aus?
- weniger aus Sicht der CPU-Auslastung als vielmehr aus Sicht der Anwendung
- Query Zeiten?
- Wie "fühlt" sich die Anwendung am Web-Frontend an?
- Wie komplex sind die Verknüpfungen der Relationen?
- Wieviele Queries werden für einen Prozess abgesetzt? -> Möglicherweise Quelle des Performanceproblems?
- Wieviele Benutzer arbeiten gleichzeitig am System?

Die Beziehungen der einzelnen Relationen aus der Anwendung heraus in die Datenbank zu ziehen ist auf jedenfall kein verkehrter Schritt. Portiert man später die Datenbank auf z.B. postgreSQL kann man hier skalieren ohne die Anwendung groß umschreiben zu müssen.

Grad so Dinge wie full text search, oder komplexe Beziehungen über mehrere Tabellen lassen sich über die Datenbank wesentlich performanter lösen als durch die "workarounds" über die php-"Anwendung".
Hier muss man bei php oft mit joins arbeiten und mehrere queries absetzen UND zusätzlich noch die erhaltenen Datensätze mit php nachbearbeiten. Alles kein Problem, wenn keine großartige Last aufs System kommt...aber wenn mal mehrere User gleichzeitig komplexere Abfragen stellen kann die Datenbank schon schnell mal ins schwitzen kommen.

Das sind alles eher Richtlinien die man im speziellen Anwendungsfall natürlich auf die Lösung anpassen sollte.

Ich seh hier eher das Problem im Anwendungsdesign selbst als vielmehr darin, dass die Datenbank "zu komplex" ist.
Wenn eh alles super läuft und auch eine Vergrößerung der Datenbank nicht absehbar ist, kannst ohnehin tun und nehmen was du willst. Es wird immer passen. Wächst das Unternehmen in Zukunft stärker und mit ihm auch die Datenbank, wirst Probleme kriegen.

@jives:
Der Vorteil in innodb ist einfach gesagt, dass es die durch REFERENCES gesetzten foreign keys auch tatsächlich durchsetzt, was natürlich jedes query komplexer macht. Dafür muss man sich die Beziehungen dann nicht explizit und komplex in der Implementierung der Anwendung abbilden.
Sprich:

a) wesentlich weniger Entwicklungsaufwand (!)
b) löst die Datenbank die Beziehungen selbst auf (ad a)
c) portiert man die Datenbank auf z.B. postgreSQL kann man hier auch skalieren. Einfach die Anwendungsschnittstellen zur Datenbank ändern und das Ding läuft wie zuvor.
d) kannst du nichts vergessen. Änderst du einen Datensatz an einer Stelle, erledigt das DBMS für dich (z.B. wie du schreibst bei UPDATE) auch in den referenzierten Datensätzen. Deine Datenbank bleibt also konsistent.

Fazit für faule:
Lieber die Funktionalität von innodb ausnutzen, als sie weglassen um Performance zu gewinnen.

edit:
php-"Anwendungen" deshalb unter Anführungszeichen, weil das sicher nicht der richtige Bergriff ist...php ist ja vielmehr eine Skriptsprache...jeder hat da eigene Begrifflichkeiten...wenn jemand die korrekte Nomenklatur weiß -> bitte gerne! :)

Wenn der post etwas unkonzeptioniert wirkt tuts mir leid, ich hab ihn in den Pausen meiner Vorlesung geschrieben...immer mal geschrieben...wieder weg...wieder was geschrieben.
Bearbeitet von EG am 01.12.2009, 15:12

ica

hmm
Avatar
Registered: Jul 2002
Location: Graz
Posts: 9823
wieso sollten php anwendungen eine schlechte skalierbarkeit haben? musst mir jetzt bitte erklären. ist eine programmiersprache wie jede andere für die es genauso 10000 frameworks gibt.

der erste schritt bevor du großartig in andere sachen zeit investiert ist wohl eine brauchbare caching lösung. danach kannst dir mal die queries ansehen und optimieren. schauen ob die indexe passend gesetzt sind etc.

aber ich seh grad - seit wann gehts hier denn um performance?

EG

thinking with portals
Avatar
Registered: May 2004
Location: 11**
Posts: 3918
Skalierbarkeit im Sinne von echter Skalierbarkeit wie sie z.B. Java Enterprise Plattformen bieten. Klar kannst mit tricksen immer viel machen, aber das ist halt alles kein wirkliches Konzept sondern wieder nur ein workaround - auch wenn er sicher ganz gut funktioniert.

Die Performance-Sache hab ich irgendwo aus folgendem heraus verstanden:

Zitat von Bogus
bisher war mir die größe der db immer egal. aktuell gibts aber 25000 kunden (das geht ja noch) und 800000 bestellpositionen. letztere db hat jetzt schon 130mb. ist bei updates und größeren db-operationen halt nervig....


full-text search ist nice. hab mir aber schon lange ne simple funktion geschrieben die das ganze mittels normalem query erledigt. konnte mich bisher nicht dazu bewegen die gesamte struktur meines 'grundpaketes für php projekte' neu zu coden........

Irgendwo scheint bei dem System (ich nehm an ein Webshop?) ja das Datenbankkonzept in die Implementierung gerutscht sein, wie das bei einfachen Anwendungen eigendlich gängig ist.
Wenns wächst wie hier kanns schonmal bei eben diesen erwähnten "updates" oder "größeren DB-Operationen" zu längeren Wartezeiten kommen.

Daraus hab ich diese Problematik gelesen...wenn ich falsch lieg is auch ned schlimm ;) Ganz im Gegenteil...gut für Bogus! :)
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz