[MySQL] MyIsam oder InnoDB?

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

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)

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.

Wenn man die InnoDB Features nicht nutzt, ist MyISAM wohl besser. Soll auch beim lesen flotter sein.

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.

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.

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.

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!