Ich schwanke seit geraumer Zeit hin und her, und her und hin, hoch und runter, Nord nach Süd, Pro und Contra, zugunsten einer businesslogiklastigen versus einer businesslogikvermissenden Datenbank.

Letzteres hat seine Vorteile, wenn ich die Datenbank wechseln möchte und die eigentliche Businesslogik in der Middleware habe. Dann benutze ich die Datenbank aber auch wirklich nur als Datenbank und nichts weiter. Die Frage bzw. Berechtigung nach einer verflixt teuren Oracle, MS-SQL, SAP HANA usw. stellt sich hier also umso heftiger. Gut, bei HANA kommt der In-Memory-Bonus mit hinzu, von dem ich aufgrund mangelnder Erfahrung in meinen Projekten nicht sagen kann, ob ich ähnliche Performance nicht auch anders erreichen kann. Zum Beispiel mit MongoDB, Cassandra, Neo4j, Postgresql, und indem ich nicht hunderttausende Euro für Spezialhardware und Lizenzen ausgeben muss. Mein leiser Verdacht ist: Ja. Allerdings hab ich dann auch keinen Support aus einer Hand, was immer der in dem Fall nun wirklich letztendlich wert ist - im Vergleich zum unvermeidlich an die Tür klopfenden Vendor-Lock-In.

Aber: Warum ein Schweinegeld für eine (kommerzielle) Datenbank ausgeben, wenn ich sie am Ende doch nur mit Standard-SQL bewerfe? Da reicht doch auch eine vernünftig eingestellte MariaDB oder MySQL mitsamt zwanghafter Vermeidung von Stored-Procedures. Und: Dann sollte ich tunlichst auch bei ANSI-SQL bleiben.

Ich muss gestehen, ich bin da kein großer Freund von. Zum einen, ich geb's zu, weil ich mit Datenbanken schlichtweg recht gut kann, mit z.B. Java aber mal so gar nicht. Andere Vorteile, die ich noch sehe: Ist die Businesslogik sehr nahe an, oder direkt in, der Datenbank, erhalte ich Bonuspunkte für die Beherrschung grosser Datenmengen "am Stück".

Hintergrund dieser philosphischen Überlegungen ist, dass ich nach ein paar Monaten Herumgehacke nun endlich mal "mein" erstes kleines Containerchen fertig habe, nämlich einen Postgresql-Container, der rdkit integriert, und am Ende auch noch funktioniert:

Hiermit sind nun also Vergleiche und Verarbeitung von chemischen Strukturen mit ganz simplem SQL möglich. Nicht, dass ich der erste mit so einem Container bin, aber meiner funktioniert tadellos - mit anderen hatte ich so meine Problemchen. Details zum Buildprozess und Meckertiraden über den DockerHub-Automatic-Build-Prozess gibt es später mal.

Zuerst einmal: Postgresql mit der rdkit-Cartridge ist schon ziemlich nettes Zeugs. Strukturähnlichkeitabfragen über ~1.6 Millionen Compounds aus der aktuellen Chembl-Datenbank dauert so zwischen 1-5 Sekunden, abhängig davon wie schnell die CPU ist und wie gut die Datenbank schon "vorgecached" hat. Auf der mlboxx, also mit Standardtakt von 1.8 GHz und Türbötäkt von 2.3 GHz liege ich entsprechend bei diesen Zeiten. Interessant war für mich hier auch, dass die Postgresql-DB hier immer "einzelfädig" vorgeht, ein Verhalten was ich später mal ergründe (zumindest soweit, wie ich es glaube verstanden zu haben ;-). Besonders weit will ich es auch gar nicht verstehen, denn ich will ja nur meine eigenen Projektideen mit geeigneten Werkzeugen durchführen und nicht etwa Datenbankadministrator werden.

Und nun, an diesem Punkt angelangt, frage ich mich, warum zur dreimal verflixten Hölle ich die Datenbank nicht zum Dreh- und Angelpunkt meiner zukünftigen Spielereien machen sollte? Je mehr Logik die Datenbank von sich aus bietet, um so schlanker kann die Mittelschicht doch sein. Per nodeJS lassen sich sogar schlanke REST-Services direkt vor die Datenbank packen, welche (theoretisch) direkt von einem GUI konsumiert werden können.

Und ich frage mich außerdem, welches Szenario ist denn nun wahrscheinlicher? Dass ich die Datenbank mal wechsle oder die Mittelschicht? Ich halte beides für ähnlich wahrscheinlich. Etwas anderes vermute ich für ein eventuelles Frontend, denn hier rennt die Entwicklung derzeit wirklich auf Steroiden herum und auch davon.

Und, ich merke noch einmal an: Ich rede hier über meine UseCases. Nicht über Websites, die Hunderte bis Tausende von CRUD-Anfragen pro Sekunde verarbeiten müssen. Im letzteren Fall dürfte es schon sehr Sinn machen, die Datenbank von unnötigem Ballast zu befreien. Aber gerade bei der Verarbeitung von größeren Datenmengen, die ich eher schlecht auf Middleware-Level cachen kann, habe ich mir bisher die Vorteile einer businesslogiklastigen Datenbank nicht ausreden lassen. Wenn es hier hart auf hart käme, dann würde ich auch eher auf z.B. ein Hadoop-Filesystem samt Spark setzen, anstatt die Businesslogik direkt in die Middleware zu klatschen.

Jemand auf StackExchange hat die Pros und Cons mal ganz gut zusammengefasst, allerdings bin ich auch hier der Meinung, dass viele der Cons (und auch der Pros!) sich direkt auf Middleware-Szenarios übertragen lassen. Daher mal eine nicht erschöpfende Link-Sammlung für Interessierte:

Ein Zusatz: Debugging von Stored-Procedures kann ganz schön schmerzhaft sein. Dat wissemawohl.

Aber schauen wir mal. Ich glaube, ich gehe den Weg der Stored-Procedures. Erstmal mit rdkit, dann mit Python, dann mit R, und dann mal ran anne Butta mit ElasticSearch-Indices unta die Haube. Die Reise wird aufregend. Und langwierig. Neben Vollzeitarbeit ist das privat betriebene Reinfuchsen in technisch-inhaltliche Forschungsspäße doch mit ganz schönen Motivationsreibungsverlusten verbunden. Hat da jemand "30-Stunden-Woche-Bei-Vollem-Lohnausgleich" gesagt??? Hallo? ;-)