PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : MySQL InnoDB Lizenzkosten



jake
29.01.11, 22:43
Hi,

ich habe eine Kurze Frage.
Wie hoch sind die Lizenzkosten für MySQL wenn zum Beispiel ein Onlineshop auf einer InnoDB-Datenbank entwickelt wurde?
Ich bin aus der MySQL-Seite nicht wirklich schlau geworden.

Hat jemand Infos und Erfahrungen (nur Lizenzierung:-)) Parat?


Vielen Dank!

jake

ThorstenHirsch
29.01.11, 22:48
Äh.... nix?

Oder hast du irgendwas spezielles verwendet?

jake
29.01.11, 22:58
Ich habe mal gehört das die Verwendung von InnoDB nicht kostenlos ist.
Ist das Quatsch?
Egal ob private oder kommerzielle Nutzung?

Danke

derRichard
29.01.11, 23:01
Ich habe mal gehört das die Verwendung von InnoDB nicht kostenlos ist.
Ist das Quatsch?
Egal ob private oder kommerzielle Nutzung?

Danke

schau dir das mal an:
http://www.innodb.com/products/innodb/license/

hth,
//richard

ThorstenHirsch
29.01.11, 23:04
Ist das ein spezieller Onlineshop, den du nutzen willst, bzw. für jemanden gebaut hast im Rahmen eines Dienst-/Werkvertrags (dann wär's kostenlos für dich/denjenigen) ooooooder hast du eine allgemeine Onlineshop-Software gebaut und möchtest diese jetzt (zusammen mit MySQL+InnoDB) als neue Software verkaufen? Wenn letzteres, dann wär's immer noch kostenlos so lange du die Software unter der GPL veröffentlichst. Ansonsten wird's kompliziert. Dann erstmal ja, dafür müsstest du eine kommerzielle MySQL/InnoDB-Lizenz erwerben, aber schau dann auch mal auf den Rest der Software, die du da vertreiben willst - da muss man ganz schön aufpassen.

nopes
31.01.11, 21:17
Lizenzkosten für MySQL nein, Kosten für InnoDB jein.

Wie auch immer die Situation ist etwa diese:
Man kann MySQL nutzen -> Kosten keine
Man kann InnoDB-Tabellen nutzen -> Kosten keine

Das Problem geht beim Backup los, mit dem kostenfreien Kram (mysql-dump) kannst du nur dann sicher sein ein wirkliches Backup zu haben, wenn du den DB-Prozess anhälst - unglaublich aber wahr.
Alternativ kannst du auch auf die Stromkosten und Umwelt pfeifen und eine Master/Slave Lösung bauen, das Backup geschickt timen, natürlich kann dann nur der Slave gesichert werden, aber das reicht - toll ist das aber nicht!!!

Nun gibt es ein "tolles" kleines Programm "ibbackup" ohne GUI und mit noch weniger Komfort und einer noch mieseren Doku. Jedenfalls kann dieser haufen Bytes ein Backup machen ohne das man dafür die DB anhalten muss und es wird trotzdem ACID (Atomicity, Consistency, Isolation und Durability) garantiert.

Das war bei MySQL wohl schon immer so, wird mit Performance begründet. Jedenfalls habe ich MySQL gekillt und Postgres genommen, ist schon der Hammer das eine DB die so einen Ruf hat(te - Oracle sei dank geht die wohl langsam aber sicher vor die Hunde) noch nicht mal ACID kann, also auch nicht Transaktionssicher ist - das ist echt - ohne Worte -

Kosten für ibbackup (http://www.innodb.com/wp/products/hot-backup/order/):

1-Year License € 390 $ 480
Perpetual License € 990 $ 1220
1-Year Email Support € 590 $ 730



Jedenfalls kann ich nur dazu raten kein MySQL mehr zu nehmen, für eine einfache PHP-Seite gerade noch im grünen Bereich - eigentlich schon eher gelb.

Wie auch immer nimm lieber ein vernünftige DB, die ACID wirklich kann und wo man ohne extra Aufwand und Kosten backupen kann...

OliverH
09.02.11, 19:10
Lizenzkosten für MySQL nein, Kosten für InnoDB jein.

Wie auch immer die Situation ist etwa diese:
Man kann MySQL nutzen -> Kosten keine
Man kann InnoDB-Tabellen nutzen -> Kosten keine

Das Problem geht beim Backup los, mit dem kostenfreien Kram (mysql-dump) kannst du nur dann sicher sein ein wirkliches Backup zu haben, wenn du den DB-Prozess anhälst - unglaublich aber wahr.
Alternativ kannst du auch auf die Stromkosten und Umwelt pfeifen und eine Master/Slave Lösung bauen, das Backup geschickt timen, natürlich kann dann nur der Slave gesichert werden, aber das reicht - toll ist das aber nicht!!!

Nun gibt es ein "tolles" kleines Programm "ibbackup" ohne GUI und mit noch weniger Komfort und einer noch mieseren Doku. Jedenfalls kann dieser haufen Bytes ein Backup machen ohne das man dafür die DB anhalten muss und es wird trotzdem ACID (Atomicity, Consistency, Isolation und Durability) garantiert.

Das war bei MySQL wohl schon immer so, wird mit Performance begründet. Jedenfalls habe ich MySQL gekillt und Postgres genommen, ist schon der Hammer das eine DB die so einen Ruf hat(te - Oracle sei dank geht die wohl langsam aber sicher vor die Hunde) noch nicht mal ACID kann, also auch nicht Transaktionssicher ist - das ist echt - ohne Worte -

Kosten für ibbackup (http://www.innodb.com/wp/products/hot-backup/order/):




Jedenfalls kann ich nur dazu raten kein MySQL mehr zu nehmen, für eine einfache PHP-Seite gerade noch im grünen Bereich - eigentlich schon eher gelb.

Wie auch immer nimm lieber ein vernünftige DB, die ACID wirklich kann und wo man ohne extra Aufwand und Kosten backupen kann...

Oha, meiner Meinung nach hängst du dich da ein wenig weit aus dem Fenster.

Ein SQL-Dump ausgeführt in einer Transaktion _ist_ ein vollständiges konsistentes Backup. Unabhängig davon kann er bei Verwendung von InnoDB eben diese auf ein LVM-Volume legen und Snapshots benutzen um jederzeit an ein konsistentes Backup zu kommen, auch ohne die Datenbank anzuhalten oder einen Slave vorzuhalten.

Wie kommst du darauf dass InnoDB kein ACID beherrschen sollte?

Gruß,
Oli

nopes
09.02.11, 20:09
Hi,

InnoDB kann das, nur MyISAM nicht! Aber ja kann sein, das ich mich etwas hinreißen lassen haben :rolleyes:

Nun wie komme ich zu der Aussage:
Chef: Ich habe da was über eine Backup Software für MySQL gehört, die ganz toll und sinnvoll sein soll, kostet aber so und soviel Euro pro Jahr, brauchen wir die?
ICH: Gedacht: Was will der bloß, seit wann muss man Geld dafür ausgeben, ist doch ein Dumper dabei. Gesagt: Ich schau mal was dahinter steckt und melde mich dann nochmal.

Gesagt getan, Doku gelesen (http://dev.mysql.com/doc/refman/5.1/de/innodb-backup.html) und ich war schon einiger maßen überrascht, wie kompliziert das da ist.

Abgesehen davon, das ich die MySQL DB vorgesetzt bekommen habe, war bzw. ist wohl bei PHP noch üblich. Hätte ich mich ganz ehrlich damit wohl nicht befasst, ich hatte bis dahin immer den Eindruck das MySQL eine ganz normale relationale Datenbank ist und damit auch komplett auf ACID setzt (selbst GUPTA konnte das), geirrt. Jedenfalls finde ich das alles sehr eigenwillig und gefährlich, da ich schon glaube das es viele so sehen, was dann wohl in die Kategorie gefährliches Halbwissen fällt.

Hinzu kommt, das MySQL von Oracle geschluckt wurde, was mir auch nicht gefiel und gefällt, was will ein DB-Herstelle mit einer weitern DB, die in vielen Bereichen durchaus als Konkurrenz gelten kann?

Jedenfalls sind wir zum Fazit gekommen, die DB nach Postgres zu portieren, da es eben eine DB ist die das einfach so kann, abgesehen davon sind fortgeschritten Features (Trigger usw.) bei Postgres schon lange dabei, während sich das bei MySQL damals noch etwas anders darstellte...

Bei der Aussage MySQL zu meiden bleibe ich jedenfalls...

bla!zilla
09.02.11, 20:14
Hinzu kommt, das MySQL von Oracle geschluckt wurde, was mir auch nicht gefiel und gefällt, was will ein DB-Herstelle mit einer weitern DB, die in vielen Bereichen durchaus als Konkurrenz gelten kann?


Weil MySQL und Oracle DB unterschiedliche Anwendungsbereiche bedienen. Die sind keine Konkurrenz, die ergänzen sich ganz gut.

OliverH
09.02.11, 20:44
Hi,

InnoDB kann das, nur MyISAM nicht! Aber ja kann sein, das ich mich etwas hinreißen lassen haben :rolleyes:

....

Bei der Aussage MySQL zu meiden bleibe ich jedenfalls...

Gut das kann ich so stehen lassen ;-)

nopes
09.02.11, 20:45
Weil MySQL und Oracle DB unterschiedliche Anwendungsbereiche bedienen. Die sind keine Konkurrenz, die ergänzen sich ganz gut.
Naja, von ergänzen würde ich nicht reden, dass eine Produkt ist für ein mittelständisches Unternehmen unerschwinglich, das andere bekommt man umsonst, auf mich wirkt es eher wie anfixen. Die Support Kosten wurden ja schon kräftig angehoben, warum dann nicht gleich auf ein Profi Produkt wechseln.

Ich werde außerdem das Gefühl nicht los, dass wir in einigen Jahren kein MySQL mehr haben, da Oracle erst ein Fork mehr oder weniger heimlich gründen wird, um MySQL dann endgültig abzustellen, dann werden die armen Forker wieder einige Zeitspäter (um die Behörden still zu halten) verklagt, weil irgendwelche Patente von Oracle gebrochen worden sein sollen. Wenn ich drauf wetten könnte würde ich es tun, Oracle ist jedenfalls kein Freund von Opensource, es probiert einfach nur seine Markmacht zu erhalten - was ja leider legitim ist...

Roger Wilco
10.02.11, 10:30
InnoDB kann das, nur MyISAM nicht!
MySQL hat nunmal im Gegensatz zu den meisten anderen RDBMS die Möglichkeit, pro Tabelle eine andere Storage-Engine (http://dev.mysql.com/doc/refman/5.5/en/storage-engines.html) zu verwenden.

Einige Storage-Engines erfüllen ACID und sind transaktional, andere nicht. Bei einigen kann man die Datendateien einfacher sichern als bei anderen, usw. Es ist daher zu verallgemeindernd zu sagen: „MySQL kann ACID.” oder „MySQL unterstützt keine Transaktionen.”.

Jede der Storage-Engines hat Vor- und Nachteile. So ist MyISAM bspw. verhältnismäßig performant bei webtypischen Anwendungsszenarien, was sicherlich zu der frühen und schnellen Verbreitung von MySQL beigetragen hat. Dafür kennt MyISAM keine Transaktionen und erfüllt ACID nicht, aber das ist in einigen Szenarien völlig in Ordnung. Die ARCHIVE Storage-Engine kann nicht einmal UPDATEs ausführen, dafür legt es die Daten extrem effektiv und kompakt auf der Festplatte ab. Auch das ist für einige Szenarien in Ordnung und sogar gewünscht.

Kris Köhntopp hat dazu vor nicht allzu langer Zeit einen interessanten Artikel (http://blog.koehntopp.de/archives/2968-Red-vs-Blue-at-Oracle,-und-ein-paar-Gedanken-zu-Postgres.html) geschrieben.