+ Antworten
Ergebnis 1 bis 6 von 6

Thema: Weg von Oracle – Alternativen zur Oracle DB – Erfahrungen

  1. #1
    User int Themenstarter

    Registriert seit
    31.07.2013
    Fachbeiträge
    34
    Genannt
    2 Post(s)
    Hallo,

    auf Grund der stark gestiegenen Lizenzkosten für die Oracle DB sind wir auf der Suche nach einer Alternative.

    Hintergrund:
    Unser Programm ist ein Bindeglied zwischen MIS und Maschine und verarbeitet/sammelt die Daten, die dabei anfallen.
    Wobei wir auch einen großen Teil an Datenauswertung in Form von Protokollen machen (falls das MIS dazu nicht in der Lage ist).
    Die Software ist stark historisch gewachsen (mind. 10 Jahre), d. h. man hat immer wieder was Neues hinzugepackt, an das man am Anfang noch gar nicht gedacht hat. Manche Teile wurden auch komplett überarbeitet. Von den ursprünglichen Entwicklern ist keiner mehr in der Firma.
    Wir sind eine 3 Mann Entwicklungsabteilung.
    Unsere Datenbankdumps sind je nach Kunden und Anzahl der angeschlossenen Maschinen zwischen 2 bis 70 GB groß. 20 bis 40 % davon sind allerdings Bilder. Wir gehen davon aus, daß sich das ganze in den nächsten Jahren bei einigen größeren Kunden auf 100 bis 200 GB ausdehnen wird.
    Ein Großteil der Logik ist mit Stored Procedures in der DB abgebildet. Diese sind sehr komplex und natürlich nur sehr sehr spärlich dokumentiert.
    Für die Protokollerstellung benutzen wir Materialized Views.
    Benutzer für die Datenbank sind nur 3 angelegt, wobei aber 2 davon vernachlässigt werden können, da diese nur in wenigen Fällen zum Einsatz kommen.
    Für die Datenbankzugriffe verwenden wir Spring und seit ca. 3 Jahren auch Hibernate.

    Ziele:
    • Weg von den Stored Procedures – diese Logik wollen wir komplett in Java abbilden.
    • Weg von Oracle.

    Als Alternativen zu Oracle würde ich PostgreSQL, MariaDB oder H2 in Betracht ziehen.
    PostgreSQL dürfte von den Möglichkeiten her Oracle ziemlich ebenbürtig sein.
    MariaDB braucht sich aber auch nicht zu verstecken.
    Da wir aber von den vielen Funktionen und Möglichkeiten der Datenbankmanagementsysteme nur einen winzig kleinen Bruchteil nutzen bzw. brauchen, wäre H2 auch eine Überlegung wert.

    Wegen der Stored Procedures schätze ich, daß wir realistisch mit mindestens 1½ bis 2 Jahren für die Umstellung rechnen müssen.

    Was ist eure Meinung dazu?
    Wer von euch hat schon eine Datenbankwechsel weg von Oracle zu XXX gemacht?
    Was sind die Fallstricke?
    Was sollte man auf keinen Fall machen?
    Sollte man sich externe Hilfe holen?
    Wie sieht es performancetechnisch aus?

    Schon jetzt vielen Dank für eure Hilfe.

    MfG
    hansmueller

  2. #2
    User Viertel Megabyte Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    371
    Genannt
    31 Post(s)
    Hallo,

    da hast du ja einiges zusammengetragen... ich schätze mal, der wichtigste Punkt in deiner Auflistung sind die recht hohe Menge binäre Daten in der Datenbank. Ich beschäftige mich zur Zeit auch mit der DB Wahl für ein System, (habe mich aber dazu entschieden Dokumente per JCR in ModeShape abzulegen). Mit PostgreSQL habe ich bislang nur gute Erfahrungen gemacht, mit MariaDB noch absolut gar keine. H2 habe ich bisher nur für kleine Entwicklerspielereien benutzt, ich kann also keine wirklichen Vergleiche bieten. Beruflich arbeite ich meistens mit Oracle.

    Zu PostgreSQL gibt es immer wieder sehr gute Ressourcen, zu BLOB Daten habe ich folgende Zusammenfassung in den Bookmarks gehabt:
    https://wiki.postgresql.org/wiki/BinaryFilesInDB

    Ist es für euch für euch tatsächlich nötig, die Files in einer DB abzulegen, oder ist das einfach historisch gewachsen? Wenn ihr jetzt eh ein großes Refactoring macht, wäre es vielleicht eine Überlegung wert die Dateien aufs Filesystem zu legen? Müssen die Bilder zwingend transaktionssicher mit den anderen Daten geschrieben werden?

    Viele Grüße
    Tim
    I am obsessed with the ancient science of "puzzle-ometry". I have discovered that within puzzles lies the secret of human intelligence, that which separates us from the common beast.

  3. Es bedanken sich:
    hansmueller (10.08.2016)
  4. #3
    User Kilobyte
    Registriert seit
    30.07.2008
    Ort
    doubled-town
    Fachbeiträge
    131
    Genannt
    7 Post(s)
    Wie kommst du auf deine Zeitschaetzung? Is die jetzt spontan ausm Bauch raus oder schon durch Zerlegen in einzelne Teile und Schaetzen jener entstanden?

    Warum weg von Stored Procedures? Hier vermute ich die groessten Probleme. Sowohl fachlicher Natur, als auch technischer. Ja, SP sind alt und schlechtes Design - aber das alles sauber OOP zu modelieren ist mehr, als die bestehenden SP anzusehen und irgendwie umzuformen. Ist dann schon eher eine komplette Neuentwicklung. Dabei wuerde ich eine NOSQL DB (z.B. Mongo) zumindest mit in die engere Auswahl nehmen - deren Einsatz ist halt extrem UseCase abhaengig.

    Wir selbst haben Oracle, allerdings ohne SP. Jedoch hab ich vor nicht allzu langer Zeit etwas mit PostgreSQL "gespielt". Dabei hab ich ein wenig den Eindruck gewonnen, dass PostgreSQL so ne Art OpenSource Oracle ist. Mit allen Vor- und Nachteilen

    Ein Versuch waere es, die SP nach PostgreSQL zu portieren. Leider hab ich da keine Erfahrung, aber ich kann mir vorstellen, dass das mit deutlich weniger Arbeit zu realisieren ginge, als die Neuentwicklung in Java. Das kann man auch toolgestuetzt machen, also ein Programm bauen, welches die OracleDB SP einliest und konvertiert. Das ist dann wiederholbar, damit gefahrlos testbar und kann Ende automatisiert fuer mehrere DB's ausgefuehrt werden.

    Externe Hilfe kann nie schaden und sei es nur, um erstmal alle Moeglichkeiten zu diskutieren.

    Performancemaessig duerfte die "SP Loesung mit Oracle" deutlich besser sein, als die "Java mit Hibernate" Loesung. Wobei ich das natuerlich ohne genaueren Einblick nicht serioes einschaetzen kann. Im Allgemeinen wuerd ich sagen, wenn die Logik viele Berechnungen mit den Livedaten macht, wird das mit einer Java Implementierung nicht wirklich schneller, da ja immer mindestens der Roundtrip zur DB dazukommt. Kann die Domain dagegen gut parallelisiert werden, ist vielleicht eine Performanceverbessung spuerbar. Letzendlich haengt die Performance aber sehr stark vom UseCase und der passenden Architektur ab, weniger von den konkret eingesetzten Produkten.

    Zu den Binaerdaten in der DB kann ich nix handfestes sagen, wir haben das aktuell auch auf dem Diskussionstisch. Mein Problem mit Filesystem ist, es ist eine weitere Komponente, die konfiguriert und gepflegt werden muss und ausfallen kann (unser NFS hat regelmaessig Macken). Zudem macht doch nach meinem Verstaendnis, eine DB nix andres als BLOBs quasi als Files auf die Platte zu schreiben (aber sie kann das effektiver, weil sie viele kleinere Files sehr einfach zu groesseren Bloecken zusammenfassen kann). Zusaetzlich kann man noch Metainformationen speichern (die Nicht-BLOB-Spalten in der Tabelle) und ueber diesen super einfach suchen. Aber wie gesagt, ich bin mir auch unsicher.
    "Drohende Diktaturen lassen sich nur bekämpfen, ehe sie die Macht übernommen haben. Es ist eine Angelegenheit des Terminkalenders, nicht des Heroismus." Erich Kästner

  5. Es bedanken sich:
    hansmueller (10.08.2016)
  6. #4
    User int Themenstarter

    Registriert seit
    31.07.2013
    Fachbeiträge
    34
    Genannt
    2 Post(s)
    Hallo,

    danke für eure Antworten.

    @Tim
    Die Binärdateien sind nicht das Problem. Diese werden nur bei Bedarf geladen. Es können sich halt nur mit der Zeit viele ansammeln, wenn der Kunde diese nicht löschen will.
    Diese Daten auf die Festplatte auszulagern bringt daher eigentlich keine Vorteile. Es ist sogar eher nachteilig, wie schalentier ausgeführt hat.
    Die Views für die Protokolle sind da eher problematisch. Ca. 150 Views, in denen die Maschinendaten unterschiedlich aufgeschlüsselt werden. Hier werden per SQL auch diverse Zeit- und Zählerstandberechnungen durchgeführt. (Hier verwenden wir keine Stored Procedures.) Die Teile schlucken Zeit.

    @schalentier
    Die Zeiteinschätzung ist tatsächlich eher aus dem Bauch raus geschätzt.
    Ich habe mal eine der Stored Procedures durch eine Implementierung in Java ersetzt.
    Das war wirklich nicht lustig. Und wenn ich mir die ganzen Packages anschaue, dann ist meine Schätzung sogar eher optimistisch.
    Du mußt dir vorstellen, daß ein Mann ca. 7 Jahre lang alles nur mit diesen SPs gelöst hat.
    Und wir wollen weg von den SPs, da es immer sehr aufwendig ist, hier Korrekturen oder Erweiterungen einzubauen.
    Aber wir werden das bei uns intern noch durchdiskutieren, ob und falls wir die SP portieren, wenn wir uns für PostgreSQL entscheiden sollten. Da gibt es auch ein paar Firmen, die auf solche Umstiege spezialisiert sind.

    Wir haben uns noch auf nichts festgelegt.
    Ich will nur ein paar Meinungen und Erfahrungen einholen.
    Man bekommt dadurch Aspekte der Problematik zu sehen, an die man vorher noch nicht gedacht hat.


    MfG
    hansmueller

  7. #5
    User int Themenstarter

    Registriert seit
    31.07.2013
    Fachbeiträge
    34
    Genannt
    2 Post(s)
    Hallo,

    wegen der stark gestiegenen Lizenzkosten und den Hardwareeinschränkungen für die Oracle DB habe ich eigentlich angenommen, daß es zu diesem Thema doch mehr Meinungen oder Erfahrungsberichte gibt.

    Müssen die meisten einfach nur nicht aufs Geld achten oder sieht man den Umstieg als zu aufwendig, riskant oder sogar als zu teuer an?
    Oder haben die meisten noch nicht realisiert, wie stark die Preise gestiegen sind?

    MfG
    hansmueller

  8. #6
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    175
    Genannt
    19 Post(s)
    Wie hoch sind denn die Lizenzkosten für so eine Typische Oracle DB Installation?

    Was wäre denn eure Migrationsstrategie?
    Erstmal auf Oracle bleiben und den Vendor-lock durch die SP beseitigen?
    Parallelbetrieb von zwei Systemen und Komponente für Komponente migrieren? Evtl. Microservice Architektur.

    Budget für eine Migration ist vorhanden?
    Wer zahlt das ganze? Stellt euch der Kunde eine Oracle DB oder bringt ihr die selbst mit? Was ist letztendlich der Benefit?
    Hatte bei meinem letzten Gig Sql-Server von MS, ebenfalls mit SP und dem ganzen Schrott am Hals. Allerdings hat von der Datenmenge her die Community Edition gereicht. Kunden hatten meist noch eine eigene Installation für alles mögliche oder eben ein paar Lizenzen übrig, wodurch dann effektiv gar keine Kosten entstanden sind.

    Zeit für eine Migration ist gegeben oder muss nebenher noch fleissig weiterentwickelt werden? Neue Kunden heisst meistens auch neue Features und zwei Jahre Wartezeit weil da intern rumgebastelt wird sind schwierig zu erklären, wenn man nebenher Geld verdienen muss.


    Schon daran gedacht, das ganze komplett in Java zu bauen? Server mit 256 GB Ram gibt es schon für 15k. Wenn nun Binärdaten auf Platte vorgehalten, dann sollte man den Rest auch gut in Ram bekommen und dann eben eine passende Strategie entwickeln das ganze zu serialisieren. Klingt hart und absurd, wird aber immer häufiger gemacht.

  9. Es bedanken sich:
    hansmueller (16.08.2016)
+ Antworten Thema als "gelöst" markieren

Direkt antworten Direkt antworten

Das Gegenteil von laut ist... ?

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Softwareentwickler Oracle (m/w)
    Von campusjaeger im Forum Angebote von Agenturen
    Antworten: 0
    Letzter Beitrag: 09.03.2016, 08:57
  2. (Installation) Oracle JDK vs OpenJDK
    Von Majora im Forum Java-Grundlagen
    Antworten: 9
    Letzter Beitrag: 31.08.2013, 01:17
  3. Oracle Developer / Oracle Entwickler (m/w) im Volkswagen Konzern
    Von AutoVisionGmbH im Forum Angebote von Agenturen
    Antworten: 0
    Letzter Beitrag: 15.07.2013, 11:32
  4. Oracle kauft Sun
    Von Jango im Forum Java
    Antworten: 3
    Letzter Beitrag: 02.02.2010, 15:37
  5. Oracle kauft Sun
    Von EagleEye im Forum Software
    Antworten: 5
    Letzter Beitrag: 22.04.2009, 15:02

Stichworte

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •