Göran Krampe über die “neuen” NoSQL – Datenbanken


Gören Krampe stellt auf seinem Blog die Folien zu einem “Breakfast Seminar” zur Verfügung:  Breakfast seminar on the new “super databases” and CouchDB

In dem Vortrag geht es um die Technik und Beweggründe hinter dem neuen Typ Datenbanken, der sich so nach und nach in der Welt der Internet-Wolke(n) etabliert, wo offenbar das Argument “Auswertung mit SQL” keine große Rolle spielt, wohl jedoch die Einfachheit des Zugriffs auf Daten und natürlich die Zugriffszeiten.

Neben einigem interessanten Zahlenmaterial von Internet-Anwendungen, die bereits solche Datenbanken einsetzen, macht Gören auch ein paar sehr interessante Bemerkungen:

When are they Interesting?

  • The Cloud of course…
  • Demanding performance specifics:
  • Huge data
  • High speed reading/writing
  • Very low latency
  • Replication, mobility
  • Web applications with simpler models
  • Lot of reads, not so much writing…
  • Or when you are stuck in ORM swamp…

Am besten gefällt mir aber:

…object databases are ”back”!

In der Tat sind Objektdatenbanken ein massiver Produktivotätsfaktor: kein OR-Mapping, kein spezifischer Datenbank-code, keine Machbarkeitsgrenzen. Wir nutzen in unseren Projekten sehr gerne eine hauseigene OODB für VA Smalltalk, die zumindest für Prototypen und kleinere Einsatzzwecke enorme Vorteile bringt. Wir sind zwar nicht Gemstone, aber für einfachere Projekte reicht das durchaus, z.B. für Intranet-Applikationen mit Seaside…

Vielleicht sollte man sich mal mit einer CouchDB-Anbindung für (VA) Smalltalk beschäftigen. Die wichtigsten Bausteine dafür sind da: HTTP-Clients und Ansätze für RESTful HTTP-Schnittstellen, Smalltalk-JSON-Adapter gibt es auch schon…

Achja: Die Idee des Breakfast Seminars ist eine Sache, über die ich auch mal nachdenken muss, klingt sehr interessant.

8 thoughts on “Göran Krampe über die “neuen” NoSQL – Datenbanken

  1. Mit OODBs habe ich mich schon beschäftigt, kann aber nicht den “totalen” Unterschied zu hierarchischen Datenbanken sehen. Aber was ganz anderes. Wie sieht es denn mit Non-SQL Datenbanken im “Business” Bereich aus. Business im Sinne Buchführung etc. Wie schlagen sich non SQL Datenbanken gerade in diesem Bereich?

    1. Friedrich,

      schön, dass Du die guten alten hierarchischen DBs zu Felde führst. Mir ging dazu schon Ähnliches durch den Kopf: ist das nicht eigentlich dieselbe Technologie wie IMS und eventuelle Konsorten vor 30, 35 Jahren anzubieten hatten? Ich mus gestehen, dass ich mit IMS nie groß in Berührung gekommen bin, aber im Studium wurde uns erklärt, wieso sie alter Schnee sind: vorgefertigte, aber dafür extrem performante, Navigationspfade und keine universelle Abfragemöglichkeit, ohne die Struktur zu kennen. Klingt schon ein bisschen nach OODBMs…
      Wir wollen aber nicht aus dem Blick verlieren (dies auch gleich als Hinweis an Marten), dass die neuen NoSQL-DBs nicht wirklich sprachspezifische OODBMs im herkömmlichen Sinne sind. Es handelt sich um einfache Name-Wert-Paar-Container, bei denen der Wert in der Regel aus einer JSON-Objektstruktur oder XML besteht. Insofern vielleicht “offener”, als manches traditionelle OODBMS.
      Ich habe keine Antwort auf Deine Frage hinsichtlich Business-Einsatz. Aber ich denke, die NoSQL-DBs werden in solchen Projekten ausprobiert werden, schliesslich sind sie hip, und für große Datenmengen sind sie offenbar gut geeignet: Facebook ist jetzt nicht direkt Mimikri, was die Datenmenge angeht.
      Interessant ist, dass noch niemand gefragt hat: Und wie ist es mit den Transaktionskonzepten?
      IMS hatte dazu klare Konzepte. Wie steht es da bei den NoSQL-DBs?
      Ich denke aber, dass die aktuelle Popularität von CouchDB durchaus nicht nur davon herrührt, dass es ein Apache-Projekt ist, sondern auch daher, dass das Ding für vieles einfach “gut genug” im Sinne von Performanz und Sicherheit ist (mit Sicherheit meine ich die Sicherheit vor Datenverlust, nicht vor Einbruch).

      1. Hm aber was ist dann der Unterschied zu Berkeley DB. Die ja “auch nur” key-Value paare kennt. Also mir erscheint es wirklich nach “alter Wein in neuen Schläuchen auszusehen”.

        Nur so alt ist der Wein offenbar nicht. Auch habe ich schon gelesen, daß hierarchiche Datenbanken immer noch ihren festen Platz auf den Mainframes haben. Leider weiß ich nicht mehr wo ich das gelesen habe. Nur antwortet das immer noch nicht die Frage was spezielle sagen wir mal in Software mir “bilanzen” der Vorteil sein soll. Also konkrete was ist der Nutzen in typischen “Business” Anwendungen. Wo man “eigentlich” nur Geldbeträge auf die “richtigen” Konten schreibt?

        1. Friedrich,

          ich verstehe die Frage nicht wirklich: Man kann wahrscheinlich so ziemlich alles irgendwie in jeder Art von Datenhaltungs-Komponente abbilden, ob es nun um CAD-Daten, biochemische Versuchsreihen, Kundendaten oder eben Finanztransaktionen geht. Die Frage der Datenbanktechnologie ist von der Fachlichkeit sicher nicht wirklich besonders stark abhängig. Wichtiger ist die Frage, wie einfach es ist, seine Daten abzulegen, wiederzufinden und abzuändern. Wieviel technischen Code brauche ich, um meine Informationen zu finden. Die Fachlichkeit ist möglicherweise ein Thema, wenn es um notwendige Schnittstellen oder externe Zugriffe auf die Daten geht. Da ist SQL sicher die am weitesten verbreitetete Technologie.
          Im Zusammenhang mit Konten, BIlanzen und Finanztransaktionen kann man für so ziemlich jede DB-Technologie eine Lanze brechen. Allerdings ist ein Buchungssatz für sich alleine meist ziemlich nutzlos, man braucht zumindest auch die beiden (oder mehr) beteiligten Konten. Sowas wird in SQL schnell komplex, und in OO-Terminologie eher nahe an der Fachlichkeit. Und doch denke ich, dass wir es bei der Frage SQL oder nicht eher mit einer technischen zu tun haben…

    2. Die Frage, die man in diesen Gebieten sicher lösen muss sind gleichzeitige Transaktionen, die sich nicht gegenseitig beeinflussen dürfen – man denke an die berühmten Geldtransaktionen, bis das Geld alle ist.

      Auf der anderen Seite muss man sich klarmachen, ob man eher über Queries auf einzelne Datensätze zugreifen möchte, oder lieber über Navigation !?

      Das beantwortet die Fragen nach einer (nicht notwendigen SQL) Anfragesprache – selbst unter Versant konnte der Einsatz der primitiven und seltsamen Anfragesprache einen erheblichen Performancezusatz bringen …

      Das erinnert mich dann eher an einen Vortrag, in der sich der Vortragende über den Sinn von DBMS vortrug – also nicht einfach das Vorhandensein einer Datenbank, sondern das ganze drumherum – das Managementsystem: Zugriffsrechte, Anfragesprache etc …….

      Bei der Beantwortung Deiner Frage, sollte man diese Überlegungen berücksichtigen

  2. Aber Joachim,

    – klar begebe ich mich in Abhängigkeiten zu einem Anbieter – aber bei Oracle, IBM oder Microsoft gibt es halt andere Sicherheiten als bei den teilweise doch recht kleinen Anbietern von OODB.

    – wir haben als Smalltalker immer nur Zugänge zu den Basisfeatures der angeschlossenen Produkte – nutzen daher diese Technologien/Produkte nicht wirklich aus. Z.B. können wir keinen Active-X Komponenten in VASmalltalk bauen – was bedeutet, dass wir Komponenten für andere Sprachen nicht anbieten können. Also verkümmert diese Technologie und wird bei VA’s nicht genutzt – obwohl in der Windows-Welt dies als normal angesehen wird.

    – und an Report-Systeme denke ich mal lieber überhaupt nicht mehr. Das Reports-Subsystem von VA ist 10 Jahre alt und man merkt das an – externe Lösungen gibt es nicht … also drücken sich die meisten Leute bei den Report-Möglichkeiten von Smalltalk oder erzeugen PDF-Dateien …

    Übrigens: Ich frage mich natürlich, wie eine Datenbank mit REST Protokoll wirklich so performant sein kann … aber das ist vielleicht nicht wirklich so wichtig.

  3. Hallo Marten,

    jaja, Nostalgie…
    Ich teile Deine Einschätzung in vielen Punkten: Ich würde nicht unbedingt sagen, dass man eine bestehende SQL-Datenbank durch eine OODB ersetzen sollte.

    Aber es gibt Einsatzszenarien, in denen eine OODB die Laufzeit eines Projektes SIGNIFIKANT verkürzt, und ich meine damit durchaus auch mal 50% und mehr. Diese sind vielleicht nicht unbedingt die Projekte, in denen Smalltalk schon seit 12 Jahren im Einsatz sind, aber für ein neu aufgesetztes Projektle (bin Schwabe) im Intranet, das über ein paar MB Daten nicht hinauskommen wird, und in dem das vgielbesungene SQL-Reporting nicht im Rampenlicht steht, sind OODBs hervorragend geeignet.
    Und mit Datenbanken vom Schlage Gemstone kann man sich noch ganz andere Projekte vorstellen, bzw. existieren ja auch. Klar, wenn Gemstone das zeitliche segnet, hat man ein Problem…
    Aber: wie sieht es denn mit den tollen XML-Features in DB2 aus? wie einfach kann man die in einem Oracle oder SQL Server abbilden? Bewegt man sich da nicht auch ausserordentlich weit von SQL-92 entfernt????

  4. Joachim schrieb:

    “In der Tat sind Objektdatenbanken ein massiver Produktivotätsfaktor: kein OR-Mapping, kein spezifischer Datenbank-code, keine Machbarkeitsgrenzen.”

    Zum 20.ten Jahrestag des Mauerfalls setzt nun auch bei Joachim die Sehnsucht und das Nostalgiedenken ein …. ?!

    Es kann in der Tat stimmen, dass die Produktivität mit OODB Datenbanken erheblich steigen kann, aber man muss auch die vielen Kehrseiten sehen:

    Die OODBs gab es schon immer und vielleicht sollten gerade wir als Smalltalker froh sein, dass sie auf breiter Front nicht wirklich aufgeholt haben – denn zunehmend wird eine sprachorientierte DB mit einer OODB verwechselt und das bedeutet für “uns” Smalltalker der Tod: wie alt würden wir aussehen, wenn wir auf diverse Datenbanken aus dem .NET oder Java Bereich zugreifen muessten, die alle doch so eine grosse Auswahl an OODB-Datenbanken haben. Wie gesagt: viele diese DBs haben keine C-API, sondern sind einfach mit einer bestimmten Sprachanbindung geschrieben worden. Dadurch verlieren diese DBs ihre Position als neutrale Datenspeicherung und -kontrolle.

    Geschlossene Systeme würde ich aus eigener Projekterfahrung nie mehr (im Zusammenhang mit Smalltalk) nutzen. Ich musste in der Vergangenheit erleben, wie die Sprachanbindung an Smalltalk von Versant während der Entwicklungsphase gekippt wurde und nicht mehr weiterentwickelt wurde …. das konnten wir 7 Jahre kaschieren und noch selber beheben, aber dann war Schluss (unter NT und virtuellen PCs). Wenn eine Wahl auf eine OODB fällt, ist die Abhängigkeit von einem DB-Anbieter noch viel schlimmer als bei relationalen Systemen …

    Auch OODBs (der etwas groesseren Art) benötigen Pflege und Wartung und auch bei diesen Systemen gelangt man an Performanceprobleme und muss dann die Tricks der Datenbank erlernen bzw. die Programmierweise entsprechend anpassen.

    Und als Kunde ? Na ja, man sollte bedenken, dass die Sprache von heute vielleicht morgen eine Nische ist – dann kann man sich freuen, wenn man die Daten in einer sprachneutralen Datenbank hat.

    Für uns als VASmalltalker wären diese DBs vielleicht nicht so sehr interessant, wenn wir auf der anderen Seite über (relationale) DB-Anbindungen verfügen würden, die auch mal die neuesten Features der Produkte unterstützen würden und sich nicht nur auf Basisfunktionalität beschränkt. So z.B. haben wir keine XML-Funktionalität bei der DB2 Datenbank – also können wir dort kaum dieses Feature nutzen … und bei Oracle wird es ähnlich aussehen.

    Wenn man bei einer relationalen Datenbank auf der grünen Wiese anfängt (was man ja auch bei der OODB machen würde), dann kann man das Design bei der DB OO freundlicher gestalten – es muss ja nicht immer der reinen relationalen Lehre gehorchen und dann kann man schon viel machen.

    Dann kommt nun langsam Glorp auch in die VA Hände und einen Mapper haben wir dann auch – auch wenn ich das Teil für so komplex halte, dass ich keine richtige Freude damit habe – aber das liegt natürlich auch daran, dass man all die alten relationalen DB-Layouts irgendwie mappen möchte.

Comments are closed.