DTR011 Java Performance, NoSQL und Kotlin

On Air

Diese Episode startet mit dem Clumsy Ninja und alten MacBook Pros. Danach gibt Tom einen Überblick über die Themen des letzten Enterprise Java User Group Meetings in Linz und André erzählt etwas von seinen Erfahrungen mit MongoDB. Nachdem aufgrund einer kleinen Themenabweichung die verwendeten “Read It Later” Services beschrieben werden, spricht André noch etwas von seinen Erfahrungen mit der Kotlin Programmiersprache von Jetbrains. Zu guter Letzt gibt es noch einen kleinen Hibernate Rant.

Einstieg

EJUG Meeting in Linz

Read It Later Services

Kotlin

IntelliJ Contracts Annotation

Hibernate

2 thoughts on “DTR011 Java Performance, NoSQL und Kotlin

  1. Hallo Leute!

    Guter Podcast wiedermal – danke fürs Erwähnen! War nett dich persönlich kennen zu lernen 🙂

    Hier noch ein paar Hinweise vom EJUG Meeting:

    – die Java Test Harness ist “JMH”: http://openjdk.java.net/projects/code-tools/jmh/

    – für flags auf der JVM für den JIT gibt es zum Beispiel “-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining “, damit sieht man in der Console wann und wie er Inlinen möchte. Nette Folien gibts auch hier: http://www.slideshare.net/CharlesNutter/redev-2011-jvm-jit-for-dummies-what-the-jvm-does-with-your-bytecode-when-youre-not-looking

    So, zu Couchbase (und CouchDB). Leider aus Zeitgründen könnte ich nicht wirklich darauf eingehen, deswegen jetzt 1-2 Sätze dazu 😉

    Couchbase, Inc. ist aus Membase, Inc. und CouchOne entstanden. Dabei wurde aus Membase Server und CouchDb ein neues Produkt, Couchbase Server gebaut. Jetzt kommt ein (für mich wichtiger ;)) Punkt: Couchbase Server ist viel mehr “Membase Server mit Indexing” als “CouchDB mit Clustering”.

    Membase Server war immer als Caching lösung gedacht und Couchbase Server ist es heute auch noch. Der Unterschied seit 2.0 (als CouchDB dazu kam) ist quasi der optionale Indexing-Mechanismus der anfährt wenn man JSON speichert. Wenn ihr euch zb Couchbase Server 1.8 anseht (quasi Membase Server noch), sieht das UI fast genauso aus, nur gibts keine “Views”.

    Technisches detail: vor 2.0 wurde SQLite als persistenz für den Cache verwendet, dann wurde die Storage Engine von CouchDB in C neu geschrieben und als append-only storage implementiert. Der einzige teil der noch halbwegs wie CouchDB aussieht is der Indexer und die Views.

    Vielleicht hole ich zu weit aus, mir ist aber die Aufklärung wichtig weil wir viel mehr ein High-Perf Cache mit Indexing sind als CouchDB mit ein bissl skalierung – und das oft ein ganz anderer Nutzungskreis ist.

    Das wars auch schon wieder 😉

    1. Vielen Dank für die Links und die Klarstellungen – vielleicht können wir das Thema ja später noch mal vertiefen.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.