[MySQL] MyIsam oder InnoDB? - Seite 2
URL: https://www.overclockers.at/coding-stuff/mysql_myisam_oder_innodb_212265/page_2 - zur Vollversion wechseln!
BuSHidO schrieb am 01.12.2009 um 16:11
myisam verwendet table locking bei INSERTS / DELETE / UPDATE. (während geschrieben wird, kann aus der gesamten tabelle nicht gelesen werden)
dies kann sehr problematisch werden, wenn applikationen nicht auf myisam zugeschnitten sind.
ich verwende myisam für eine große datenbank auf der nicht viel parallel gearbeitet wird. (> 1 Mrd Datensätze)
innodb verwendet row locking und hat durch foreign keys bzgl. datenintegrität enorme vorteile. ist allerdings langsamer und braucht viel mehr speicherplatz.
innodb würde ich für "normale" web-anwendungen empfehlen.
jives schrieb am 01.12.2009 um 16:15
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.
Das ist ja eine ewige Debatte 
Ein interessanter Artikel zu dem Thema: http://www.sitepoint.com/blogs/2004...doesnt-get-php/
Ansonsten Danke für die interessanten Hinweise und Ausführungen! Versteh ich das richtig, dass mit (z.B.) InnoDB zwar JOINs und Co. in der Applikation bleiben, aber alle Referenzen und die Datenpflege (DB-Integrität) vollständig in die DB selbst verlegt werden können?
ica schrieb am 01.12.2009 um 16:27
Ansonsten Danke für die interessanten Hinweise und Ausführungen! Versteh ich das richtig, dass mit (z.B.) InnoDB zwar JOINs und Co. in der Applikation bleiben, aber alle Referenzen und die Datenpflege (DB-Integrität) vollständig in die DB selbst verlegt werden können?
joins in der applikation?
die db-integrität wird mit innodb und korrekten referenzen gewährleistet ja. immer ersparts dir das manuelle abfragen dadurch aber auch nicht. beispielsweise wenn du verweise auf bilder/hochgeladen daten in der db speicherst musst/solltest du natürlich bevor der eintrag im nirvana verschwindet die files löschen.
jives schrieb am 01.12.2009 um 16:34
joins in der applikation?
Ganz, ganz schlecht ausgedrückt Und auch gerade eben durchschaut, glaube ich. Vielen Dank jedenfalls!
EG schrieb am 01.12.2009 um 16:52
myisam verwendet table locking bei INSERTS / DELETE / UPDATE. (während geschrieben wird, kann aus der gesamten tabelle nicht gelesen werden)
dies kann sehr problematisch werden, wenn applikationen nicht auf myisam zugeschnitten sind.
ich verwende myisam für eine große datenbank auf der nicht viel parallel gearbeitet wird. (> 1 Mrd Datensätze)
innodb verwendet row locking und hat durch foreign keys bzgl. datenintegrität enorme vorteile. ist allerdings langsamer und braucht viel mehr speicherplatz.
innodb würde ich für "normale" web-anwendungen empfehlen.
Das ist schon ein sehr gutes Statement...kann man so unterschreiben! 
Wär fein, wenn Bogus sich nochmal zu Wort melden würd inwiefern ihm das jetzt geholfen hat, oder es noch unklarer geworden ist.
Ringding schrieb am 01.12.2009 um 18:43
Das Transaktionsmodell von InnoDB ist einfach wesentlich intuitiver als dieser MyISAM-Pfusch. Hinzu kommt, dass wir in der Firma bei unseren Kunden immer wieder Probleme mit MyISAM bemerken, an denen wir per definitionem nicht schuld sein können . Ich wundere mich zwar, dass das passiert, aber es passiert nachweislich immer wieder. Und die Hardware verdächtige ich auch nicht – sind durchgängig HP-Server mit SmartArray RAIDs (SAS klarerweise).
Ein paar "kleine" Tabellen bei Kunden (paar hundert MB) sind noch als MyISAM geführt, und alle paar Wochen passiert es dabei bei einer, dass der Index plötzlich 60-100 GB groß wird und die Platte fast vollmacht. Dann muss man "repair table" machen, und alles läuft wieder, aber sehr vertrauenserweckend ist das wahrlich nicht.
Die großen Tabellen (200-400GB) laufen alle als InnoDB, und da haben wir in mittlerweile etlichen Jahren noch nie auch nur den Anflug eines Problems gehabt.
Bogus schrieb am 02.12.2009 um 12:56
ok. bei mir siehts so aus:
ist ein webshop (ich kann's ja sagen: juv.at) mit diversen funktionalitäten im backend (versandwesen, kundenverwaltung, kalkulation, projekte). da gibts zwar nen relativ großen datenbestand, aber keine massenanstürme auf die homepage. es arbeiten auch maximal 1-2 mitarbeiter gleichzeitig im system (aber nicht in den selben bereichen).
bis auf weiteres also alles kein problem. auch in sachen performance gibts NULL probleme. liegt bei edis.at und ist 1a schnell (postnuke und typo3 sind weitaus langsamer).
großartige features oder non-plus-ultra lösung ist bei dem auftragsvolumen nicht drin. wie immer muss alles 'günstig' sein
danke für alle antworten. ich weis jetzt im groben bescheid und werde nach nem backup einfach auf myisam umstellen.
die sache mit innodb guck ich mir dann an wenn mal bedarf kommen sollte.
that schrieb am 02.12.2009 um 21:52
Wie man eine Datenbank ohne Transaktionen, Locking oder Foreign Keys betreiben kann, ist mir ein Rätsel.
Bogus schrieb am 02.12.2009 um 22:18
und mir ist es ein rätsel wie man zb. in nem kleineren und unspektakulären php-script klassen und objektaufrufe (ich denke das heist so) verwenden kann um das ganze mehrsprachig zu realisieren.
meiner meinung nach ist alles eine frage der anforderungen. hätt ich alle bisherigen aufträge 'voll profesionell' erledigen wollen, hätten wohl 90% aller kunden nicht die finanziellen mittel dafür gehabt.
wie schon erwähnt gebe ich zu das ich nichts profesionell gelernt habe und seit ca 5 jahren keine weiterbildung mehr mache. alles learning by doing. und da ich es gewohnt bin auf in simplen umgebungen 'strukturiert' zu coden gab es nie probleme.
müsste ich jetzt projekte für mehrere 1000 bestellungen/schreibzugriffe pro tag coden, muss ich sicher anders denken. aber bisher waren selbst die 'großen' (ERP, CRM, Faktura, ...) projekte nur schwach frequentiert.
kein bedarf an transaktionen bisher (hatte ich schon mal angedacht)
kein locking nötig (keine situation denkbar bei der daten asynchron werden)
und die foreign-keys hab ich scheinbar software-seitig gelöst
naja. seit ich von perl auf php umgestiegen bin nenne ich mich eh nicht mehr 'programmierer'. aber 'coder' hört sich auch so doof an 
und als 'scripter' fühl ich mich immer auf ne stufe mit flash oder javascript (von vor 8 jahren) gesetzt
naja: grundsatzfrage: was ist einer der variablen und texte in nem php-script selbst ändern kann? (viele glauben von sich selbst sie könnten damit bereits 'programmieren')
und wie nennt man dann einen der von a-z eigenständige und umfangreiche lösungen 'schreibt'?
vor ca 8 jahren habe ich bei ***** (großer österreichischer provider) begonnen, und ohne php überhaupt zu können gleich angefangen die komplette faktura (kunden, mahnwesen, rechnungen, artikelstamm, etc.) und serververwaltung (domains, vhosts, emails, subdomains, verzeichnisschutz, ftp, dateimanager, etc) in php zu realisieren. nach ca 2 jahren war ich damit fertig.
auch wenn ****** inzwischen um ein zigfaches größer ist, und der neue programmierer schon seit ca 5 jahren eine 'ablöse' codet, so konnte er 'mich' bisher noch immer bei weitem nicht vollständig ersetzen.
und es gibt keine probleme mit dem teil. obwohl es seinerzeit auf nem einzelnen server lief und mittlerweile ein cluster-system konfiguriert.
ok, zugegeben, dort gab es locking und ähnliches. aber auf system-ebene und file-basis. DB war interbase.
....strichpunkt: in mysql hab ich das bisher nie benötig.
meepmeep schrieb am 02.12.2009 um 22:19
Wie man eine Datenbank ohne Transaktionen, Locking oder Foreign Keys betreiben kann, ist mir ein Rätsel.
fullack, mir auch
COLOSSUS schrieb am 02.12.2009 um 22:23
[…]
....strichpunkt: in mysql hab ich das bisher nie benötig.
Mag sein, mag nicht sein.
Fakt ist, dass in fuenfzig Jahren Computer Science nicht nur Luftschloesser gebaut wurden, und die von dir gemiedenen Konzepte (ueberlebens)wichtig und richtig sind. Wenn du in deinen Projekten einfach weitermachst wie bisher, frei nach dem Motto "ach, irgendwie wird's schon gehen", dann wird es irgendwann, das gebe ich dir hiermit schriftlich, ganz uebel krachen.
Bogus schrieb am 02.12.2009 um 22:25
@colossus: full ack!
ist mir vollkommen bewusst. daher mach ich auch nur noch 'ausgewählte' projekte. und über kurz oder lang werd ich (wegen 2ter firma) sowieso keine zeit mehr für's coden haben.
Bogus schrieb am 18.11.2016 um 21:12
*necro*
nur 7 jahre später, und man denkt ganz anders.
arbeite mich gerade in objektorientierte programmierung ein, und muss mich nun auch mit svn/git und frameworks (rest, slim, soap) befassen.
faszinierend, wie das leben so spielt
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025