nekropole - Do 08.01.04 13:04
Titel: MySql - Beschränkung der Größe bei InnoDB?

---

Aus meiner Entwickler-Gruppe hat mich folgende Anfrage erreicht:

Zitat:

Die InnoDB Versionen erlauben die Speicherung der Dateiverkünpfungen, so daß diese via Revere Engenierung von entsprechenen Design Tools eingelesen und grafisch aufbereitet werden können. Ich weiß [jedoch (Anm.d.V.)] nicht ob sie in der Lage sind alle Daten zu fassen oder ob die freie Version von InnoDB in MySQL eine Größenbeschränkung besitzt.

Es handelt sich um eine Internet-Literatur-Daternbank im Science Fiction Bereich für deutschsprachige SF-Literatur und die Historie der übergebenen, geänderten und gelöschten Datensätze soll gespeichert werden. Wir rechnen (ausgehend vom jetzigen Datenbestand) mit mehreren GB an Daten.

Kann jemend diese Frage beantworten?

neojones - Do 08.01.04 14:29

---

Warum nutzt Du nicht myISAM?

Meines Wissens gibts derzeit kein einziges Tool, das das Reverse-Engeneering unterstützt, weil ODBC die Informationen dazu nicht zurückliefern kann.

nekropole - Do 08.01.04 15:29

---

Soweit ich das verstanden habe, werden die InnoDB-Tabellen desshalb gebraucht, weil die Verarbeitung der gelieferten Daten bei der Konvertierung auf die Web-Datenbanken extern erledigt wird. Und dort das mit RI funktioniert. Ich glaube mit einer Nexus-Datenbank und dem EMS MySQL Managers 2. Nagle mich aber jetzt nicht fest. Wenns dich interessiert könnte ich mich diesbezüglich erkundigen. Die Gesamtdaten liegen dann aber wieder gesamt auf einem MySql-Server Ich stell hier nur die Fragen, weil ich es übernommen habe solche Dinge zu klären, damit die anderen arbeiten können.

Dazu einige Auszüge aus unserer Maillist:

Zitat:

Die lokalen mySQL Datenbanken benutzen die INNODB Engine und nicht die MYISAM Engine. INNODB unterstützt FOREIGN KEYS und dies ist die Voraussetzung, für die Speicherung der Tabellenbeziehungen innerhalb der Datenbank, so daß diese graphisch aufbereitet werden kann.

Zitat:

Der Hauptunterschied zwischen MYISAM und INNODB ist die Unterstützung von RI durch FOREIGN KEYS und die Unterstützung von Transaktionen. Beide Unterschiede kommen erst zum Tragen, wenn man Datenverarbeitung und nicht Datenauswertung betreibt. Die Datenverarbeitung auf dem ISP Server beschränkt sich nur auf die Erfassung von Änderungswünschen und sollte daher nur INSERT Befehle erzeugen. Eine Änderung auf myISAM ist also nicht notwendig. Ich benötige RI in erster Linie zu Dokumentationszwecken, i.e. wegen der Möglichkeit mit REFERENCES das Ziel einer Verknüpfung angeben zu können.

Zitat:

Die Datei enthält einen Screendump des EMS MySQL Managers 2. Dieses (kommerzielle) MySQL Frontend besists einen Visual Database Designer. Der Mittelteil zeigt die Verknüpfungen userer Dateien nach Aktivierung des Reverse Engineer Tools. Diese Möglichkeit war der Grund warum ich für die Import und Hauptdatenbank zur MySQL Alternative INNODB gewechselt bin. Leider ergibt der Versuch das Diagram als Grafik zu speichern nur die Fehlermeldung (NOT ENOUGH MEMORY).

Zitat:

Mein Konvertierungsmodul ist nun in der Lage die mySQL Scripte zum Anlegen der Tabellen automatisch zu erzeugen sowie eine HTML Beschreibung sowohl der Struktur innerhalb der von mir benutzten Nexus Datenbank als auch der MySQL Scripte zu erzeugen. Der nächste Schritt ist die Erzeugung der INSERT Befehle um die Daten von Nexus nach MySQL zu konvertieren.

Wenn interessiert:
unsere Datenbankgruppe bei Yahoo [http://de.groups.yahoo.com/group/SFHINX/]
oder
unsere Web-Fontend-Gruppe auf sourceforge.net [https://sourceforge.net/projects/dsfdb/]

ich glaube speziell im Bereich der Datendateinübertragung von einem Server auf den anderen und bei den Konvertern sind noch einige Probleme nicht angepackt die für fortgeschrittene Delphi-Programmierer auch interessant sein könnten.

neojones - Do 08.01.04 15:51

---

Also,

eine gescheite Datenbankdokumentation sorgt dafür, dass die Daten fürs Re-Engineering gar nicht in der Datenbank abgespeichert werden müssen. Dafür reicht i.d.R. bereits der Einsatz von Microdoof Visio oder eines entsprechenden Derivats.

Zur Transaktionskontrolle: Da sollte euer Entwickler wissen, dass das ar...-langsam wird. Deswegen wurden ja die atomic operations bei myISAM eingeführt. Um Probleme bei Data Transactions zu umgehen, stellt mySQL bei myISAM bereits LOCK TABLE zur Verfügung. Ausserdem lässt sich die Transaktionskontrolle "simulieren", indem man temporäre Tabellen erzeugt.

Zudem gesteht sich selbst mySQL AB ein, dass die Transaktionskontrolle noch nicht ausgereift ist und dies auch nie werden wird. Ich zitiere die mySQL-Dokumentation, Kapitel "Transactions and atomical operations":

Zitat:

Even a transactional system can lose data if the server goes down. The difference between different systems lies in just how small the time-lap is where they could lose data. No system is 100% secure, only ``secure enough.'' Even Oracle, reputed to be the safest of transactional database systems, is reported to sometimes lose data in such situations. To be safe with MySQL Server, whether using transactional tables or not, you only need to have backups and have the binary logging turned on. With this you can recover from any situation that you could with any other transactional database system. It is always good to have backups, independent of which database system you use.

Zum Thema "Geschwindigkeit" aus dem selben Kapitel:

Zitat:

However, even if you are new to the atomic operations paradigm, or more familiar with transactions, do consider the speed benefit that non-transactional tables can offer on the order of three to five times the speed of the fastest and most optimally tuned transactional tables.

Zu den Risiken von Transaktionen lässt sich die Doku ebenfalls aus (nämlich das ungewollte Rollback):

Zitat:

``Atomic,'' in the sense that we mean it, is nothing magical. It only means that you can be sure that while each specific update is running, no other user can interfere with it, and there will never be an automatic rollback (which can happen with transactional tables if you are not very careful). MySQL Server also guarantees that there will not be any dirty reads.

Man verzeihe mir meine radikale Sicht der Dinge, aber Transaktionskontrolle wird nur von Leuten benötigt, die schon vorher wissen, dass Sie selbst oder Ihr Programm Fehler macht.

Warum konvertiert ihr die Daten von einem Datenbanksystem in ein anderes? Wenn Ihr auf einem System eine Datenerfassung und Aufbereitung und auf dem anderen System (2 getrennte Server) eine Datenauswertung fahrt (man merke an: Iterative Datenauswertung benötigt bei mySQL erheblich länger als Datenaufbereitung, wenn damit interne Statements gemeint sind. Grund: Die Auswertung unterstützt sämtliche Tabellenverknüpfungen, die Aufbereitung hingegen nicht!) dann benutzt doch einfach eine One-Way-Replikation. Wenn Ihr hingegen auf einem System eine Datenerfassung und auf dem anderen eine Datenaufbereitung macht, dann macht einfach einen Dump über die Servergrenze hinweg.

Fernab dessen ist mySQL mit Beowolf clusterbar. mobile.de zum Beispiel bereibt einen sehr großen mySQL-Cluster.

Nächste Frage: Warum setzt ihr auf EMS? Wer weiß denn schon, wie lange es die Firma noch gibt? Wenn man schon die Vorteile eines freien Datenbanksystems nutzt, warum sollte man diesen Vorteil durch kommerzielle Module kaputt machen? (Sag selbst ich, der sein Geld mit kommerziellen mySQL-Tools verdient *g*)

Solltet ihr die Foreign-Keys innerhalb eurer Programmlogik benötigen, weil euer Programmierer nicht richtig mit JOINs umgehen kann: mySQL wird in absehbarer Zeit auch für myISAM Foreign Keys anbieten.

Zitat:

For other table types, MySQL Server currently only parses the FOREIGN KEY syntax in CREATE TABLE commands, but does not use/store this info. In the near future this implementation will be extended so that the information is stored in the table specification file and may be retrieved by mysqldump and ODBC. At a later stage, foreign key constraints will be implemented for MyISAM tables as well.

Die Dokumentation nennt beim Einsatz von Foreign Keys eine ganze Reihe von Nachteilen:

Zitat:

Mistakes, which are easy to make in designing key relationships, can cause severe problems--for example, circular rules, or the wrong combination of cascading deletes. Additional checking on the database level affects performance, for this reason some major commercial applications have coded this logic on the application level. It is not uncommon for a DBA to make such a complex topology of relationships that it becomes very difficult, and in some cases impossible, to back up or restore individual tables.

Um noch einige Nachteile von InnoDB hinterherzuwerfen:

http://www.mysql.com/documentation/mysql/bychapter/manual_Table_types.html#InnoDB_restrictions

Und um die allererste Frage zu beantworten, ob InnoDB in der freien Version eine Beschränkung hat:

Zitat:

The default database page size in InnoDB is 16 KB. By recompiling the code one can set it from 8 KB to 64 KB. The maximun row length is slightly less than half of a database page in versions <= 3.23.40 of InnoDB. Starting from source release 3.23.41 BLOB and TEXT columns are allowed to be < 4 GB, the total row length must also be < 4 GB. InnoDB does not store fields whose size is <= 128 bytes on separate pages. After InnoDB has modified the row by storing long fields on separate pages, the remaining length of the row must be less than half a database page. The maximun key length is 7000 bytes. On some operating systems datafiles must be < 2 GB. The combined size of log files must be < 4 GB. The maximum tablespace size is 4 billion database pages. This is also the maximum size for a table. The minimum tablespace size is 10 MB.

Viele Grüße,

Matthias

P.S.: Ich hab kein Problem damit, wenn man mir widerspricht und lasse mich gerne eines besseren belehren ;-)

chomse - Do 08.01.04 17:16

---

Zitat:

Solltet ihr die Foreign-Keys innerhalb eurer Programmlogik benötigen, weil euer Programmierer nicht richtig mit JOINs umgehen kann: mySQL wird in absehbarer Zeit auch für myISAM Foreign Keys anbieten.

Wir brauchen Foreign Keys weil wir RI benötigen.

Zitat:

Nächste Frage: Warum setzt ihr auf EMS? Wer weiß denn schon, wie lange es die Firma noch gibt? Wenn man schon die Vorteile eines freien Datenbanksystems nutzt, warum sollte man diesen Vorteil durch kommerzielle Module kaputt machen? (Sag selbst ich, der sein Geld mit kommerziellen mySQL-Tools verdient *g*)

Wir setzen nicht auf EMS. Die Tools sind eben billiger als die Erstellung von
eigenen Hilfsprogrammen.

Zitat:

Warum konvertiert ihr die Daten von einem Datenbanksystem in ein anderes? Wenn Ihr auf einem System eine Datenerfassung und Aufbereitung und auf dem anderen System (2 getrennte Server) eine Datenauswertung fahrt (man merke an: Iterative Datenauswertung benötigt bei mySQL erheblich länger als Datenaufbereitung, wenn damit interne Statements gemeint sind. Grund: Die Auswertung unterstützt sämtliche Tabellenverknüpfungen, die Aufbereitung hingegen nicht!) dann benutzt doch einfach eine One-Way-Replikation. Wenn Ihr hingegen auf einem System eine Datenerfassung und auf dem anderen eine Datenaufbereitung macht, dann macht einfach einen Dump über die Servergrenze hinweg.

Ganz einfach. Die Datenkonvertierungsprogramme benutzen überhaupt kein SQL sondern arbeiten direkt auf den Tabellen.

Zitat:

eine gescheite Datenbankdokumentation sorgt dafür, dass die Daten fürs Re-Engineering gar nicht in der Datenbank abgespeichert werden müssen. Dafür reicht i.d.R. bereits der Einsatz von Microdoof Visio oder eines entsprechenden Derivats.

Wenn die Diagramme direkt aus der Datenbank erzeugt werden können,
braucht man keine Dokumentation mehr. Wir benutzen den agilen Ansatz mit der Prämisse - Schreibe eine Dokumentation nur wenn Du es nicht
vermeiden kannst.

neojones - Do 08.01.04 17:38

---

Seltsame Entwicklungsphilosophie ;-)

Naja, die Frage mit der Beschränkung der Größe der Tabellen sollte ja über den Auszug der Dokumentation hinreichend geklärt sein.