JVM: All content tagged as JVM in NoSQL databases and polyglot persistence
FnordMetric looks like an interesting library for collecting and visualizing timeseries:
According to the docs, the framework has 3 components:
FnordMetric Classic: a DSL for processing data streams and building web-based dashboards.
It’s built in Ruby and uses Redis.
FnordMetric Enterprise: a JVM-based timeseries databases
My only question is why building a new storage engine for the Enterprise component when there are already so many good tools for doing this. Other than that, I really liked the screenshot.
Original title and link: FnordMetric: A Framework for Collecting and Visualizing Timeseries ( ©myNoSQL)
BigCache addresses this problem by persisting the cached data in memory within the same JVM process, but outside the JVM heap. This prevents the Garbage Collector from interacting with the cache’s memory zone, allowing the JVM heap size to be scaled based on processing needs only. While this solution is slightly slower than in-heap data access, it is faster than disk or network data transfers. These aspects make BigCache a solution that not only delivers performance, but can also scale up to tens or hundreds of gigabytes of RAM on the same machine.
This sounds like an open source (Apache licensed) alternative to Terracotta’s BigMemory.
Original title and link: What Is BigCache: Off-Heap Caching Solution for the JVM ( ©myNoSQL)
A couple of most notable NoSQL databases targeting large scalable systems are written in Java: Cassandra, HBase, BigCouch. Then there’s also Hadoop. Plus a series of caching and data grid solutions like Terracotta, Gigaspaces. They are all facing the same challenge: tuning the JVM garbage collector for predictable latency and throughput.
Jonathan Ellis’s slides presented at Fosdem 2012 are covering some of the problems with GC and the way Cassandra tackles them. While this is one of those presentations where the slides are not enough to understand the full picture, going through them will still give you a couple of good hints.
For those saying that Java and the JVM are not the platform for writing large concurrent systems, here’s the quote Ellis is finishing his slides with:
Cliff Click: Many concurrent algorithms are very easy to write with a GC and totally hard (to down right impossible) using explicit free.
Enjoy the slides after the break.
Until yesterday I didn’t know there’s an attempt to implement the R language on the JVM. But there’s one: renjin. And it sounds like it needs some helping hands to accomplish its goal of reaching a 1.0 release in 2012.
In case you’d wonder why R on the JVM—same question have been asked so many times related to JRuby, Jython, etc—just think of:
- it would allow access to the tons of Java libraries
- it would integrate seamlessly with tools like Hadoop
If you are ready to start contributing head on to the Renjin’s plan of attack for 2012 page and learn where your help would be needed.
Original title and link: Call to Arms: Renjin, R Implementation on JVM Needs Contributions ( ©myNoSQL)