php.de

Noch ein Thema, um das ich mich bis heute noch nicht gekümmert habe. Es geht um die Performance von Datenbankabfragen.

InnoDB beherrscht 2 Arten von lockings:

- Tabellen-locking mittels LOCK TABLES
- row-level-locking mittels FOR UPDATE oder LOCK IN SHARE MODE

Der Nachteil von LOCK TABLES: Die komplette Tabelle wird gesperrt

Die Nachteile von row-level-locking sind:

- erhöhter Programmieraufwand:
Es darf eigentlich keine "normalen" SELECTs mehr geben.
Es muss also praktisch bei jedem SELECT eine Transaktion gestartet werden.
Gefahr, dass man bei irgendeinem SELECT das LOCK IN SHARE MODE vergisst.

- Kein Caching im MySQL möglich.

Wofür entscheidet ihr euch? Hat hier schon jemand in Performancetests geschaut, welche der beiden Varianten besser ist?

Mister Ad

eagle275

also ganz ehrlich - du sorgst dich um "micro"-Performance .. ich verwende weder Lock Tables- weil das ja bei MyIsam Standard war und ich es ablehne .. Multiuser-Anwendungen müssen halt gleichzeitig auf die gleiche Tabelle zugreifen können

Also kommt bei mir InnoDB mit ganz normalen Zeilen-Lock zum Einsatz, aber ohne den ganzen Aufwand bei Select - und es klappt hervorragend - und für Transaktionen ... die stehen bei mir auf "auto" - und daher geht Caching auch ganz wunderbar in MySQL - der hat ja spezielle eigene Caches, nur für InnoDB.

MyIsam's Lock Tables ist schnell, wenn quasi nur gelesen wird - sobald etwa gleichviel gespeichert und gelesen wird, hauen einem die blockierten Tabellen aber sowas von auf die Anwender-Erfahrung .. Und erkläre mal den Usern "du darfst jetzt nicht speichern, weil Admin A / B / C gerade einen Dump von 5000 Datensätzen einspielt .. in 1 Stunde gehts dann weiter ... die erschießen dich mit nem vergifteten Strick oder so ähnlich ...

InnoDB kommt bei solch ausgewogenen Zugriffen wesentlich besser .. und bisher hab ich noch keinen zwingenden Grund für explizite Transaktionen gefunden (bezogen auf meine Anwendungsfälle! - ich mach ja keine Buchhaltung damit, wo Änderungen in 2...X Tabellen nur gemeinsam geschehen dürfen).

__________________
"Irren ist männlich", sprach der Igel und stieg von der Drahtbürste

php.de

Du meinst, man kann bei InnoDB ein row-level-locking ohne FOR UPDATE bzw. LOCK IN SHARE MODE machen? Woher hast du diese Information?

eagle275

row-level-Locking wie du es nennst, ist die "normale" Arbeitsweise von InnoDB, wird im Manual und entsprechenden Erklärungen immer als DER Unterschied zu MyIsam dargestellt (neben Transaktionen), wobei das automatische Locking einer Zeile quasi nur für die kurze Zeit eines INSERT / UPDATE / REPLACE gilt, länger muss ja die Zeile nicht blockiert werden, ich selbst habe für meine Hauptanwendung einen Sperrmechanismus drübergestülpt, der verhindert, dass mehr als 1 User den gleichen Datensatz schreiben kann. Der erste User erhält Schreibzugriff, für die weiteren User ist der Datensatz lesbar, aber die können nicht speichern - dafür muss der "erste" User seinen Datensatz speichern und schließen
und für den Rest - um ehrlich zu sein, ich wusste nicht mal, dass man solchen Aufwand treiben kann / muss - vielleicht für dein gemeinsames Löschen ganzer Tabellen-Abschnitte ... bei mir betrifft das Anwendungsszenario einzelne Datensätze, die ihrerseits 1:1 mit weiteren Datensätzen verknüpft sind - und Löschen ist bei mir gar nicht vorgesehen.... Wegen Revisionssicherheit werden bei mir Datensätze nur über Flags 2-stufig archiviert, verbleiben aber in der / den Tabellen, wobei mein gesamtes Datenaufkommen eher bescheiden ist (nach 1,5 Jahren kommen wir auf ca 30-40 MB, Wachstumsrate max 1-2 MB pro Monat)

__________________
"Irren ist männlich", sprach der Igel und stieg von der Drahtbürste

php.de

Wenn man das sowieso nie brauchen würde, gäbe es gar kein FOR UPDATE oder LOCK IN SHARE MODE.

eagle275

dein Anwendungsfall aus der anderen Frage liefert ein Beispiel, wo es vielleicht gebraucht wird - aber wie gesagt, ich lösche keine Blöcke mehrere Zeilen aus der Datenbank ...von daher wird von jedem User nur ein Datensatz geöffnet und geschrieben und damit macht es voll Sinn, dass ich nicht noch explizit weitere Locks setze, sondern innoDB seine "hauseigene" Blockierung genau der gerade geschriebenen Zeile macht

__________________
"Irren ist männlich", sprach der Igel und stieg von der Drahtbürste

lstegelitz

MyIsam + delayed INSERTs nutze ich z.Zt. für Logs... das ist schon ziemlich performant, wenn man die Daten nicht sofort wieder braucht. Ich bastel mir ebenfalls grade einen eigenen Sperr-Mechanismus, der mit MEMORY Tabellen arbeitet, rattenschnell aber flüchtig.

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

php.de

Hört sich sehr interessant an. Verrätst du uns noch mehr darüber?

lstegelitz

Ich möchte das mal benutzen, um Sperren auf Applikationsebene setzen zu können. Im Kern geht es um Prozess-Synchronisation eines last-verteilten Systems über die Datenbank. Grob gesagt bastel ich also ein Mutexsystem für "critical sections".

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

php.de

Und wie schaut dein Mutexsystem aus? Wie schaut das Konzept aus?