3 ms·

This is correct; the standard approach here is to use regular c-style memory management for the data the system is managing, and the JVM heap only for the datab

This is correct; the standard approach here is to use regular c-style memory management for the data the system is managing, and the JVM heap only for the database "infrastructure". This hybrid approach gives the benefit of a managed runtime and safety of GC for most of your code, but allows the performance of raw pointers/malloc for key code paths. Some examples of this pattern on the JVM: - The Neo4j Page Cache, Muninn, https://github.com/neo4j/neo4j/blob/3.4/community/io/src/main/java/org/neo4j/io/pagecache/impl/muninn/MuninnPageCache.java#L58 https://github.com/neo4j/neo4j/blob/3.4/community/io/src/mai... - The Netty projects implementation of jemalloc for the JVM: https://github.com/netty/netty/blob/4.1/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java https://github.com/netty/netty/blob/4.1/buffer/src/main/java...

tkahnoski 9y ago
If so any JVM based datastore could probably benefit. I wonder how long before we see a similar result from ElasticSearch. (Only other huge JVM based store I can think of).
- ddorian43 9y ago
  Hbase is going offheap as much as possible. Voltdb uses java for management and c++ for low-level. They will write c++ in java eventually. Depending on how much performance you REALLY need. The same for elasticseach, if you want performance you need to do the same thing scylladb did to cassandra (per-core-sharding, skip filesystem across cores etc)
  - ddorian43 9y ago
    In elasticsearcch terms, vespa.ai, which claims better performance/scalability/maintanability uses c++ for lucene layer and java for the solr/elasticsearch layer. There are blog posts speeding lucene by 2x+ by changing some stuff to c/c++. There are libraries (trinity) claiming 2x+ performance . There is google-engineer saying "bigtable is 3x faster than hbase" that I've read.
- itronitron 9y ago
  People with an interest may want to check out Azul's Zing JVM and the following blog post testing it out with Lucene... http://blog.mikemccandless.com/2012/07/lucene-index-in-ram-with-azuls-zing-jvm.html http://blog.mikemccandless.com/2012/07/lucene-index-in-ram-w...
ndesaulniers 9y ago
> but allows the performance of ... malloc for key code paths. Everything is relative, I guess.
- jakewins 9y ago
  Hah :) I don't mean that malloc itself is fast, I mean that having non-jvm heap memory is fast. A permanent memory block on the JVM heap can't use pointers to refer to it, since GC moves objects around. And even though those blocks will never be collected, they make up additional work for the GC to track.

tkahnoski 9y ago

If so any JVM based datastore could probably benefit. I wonder how long before we see a similar result from ElasticSearch. (Only other huge JVM based store I can think of).

ddorian43 9y ago
Hbase is going offheap as much as possible. Voltdb uses java for management and c++ for low-level. They will write c++ in java eventually. Depending on how much performance you REALLY need. The same for elasticseach, if you want performance you need to do the same thing scylladb did to cassandra (per-core-sharding, skip filesystem across cores etc)
- ddorian43 9y ago
  In elasticsearcch terms, vespa.ai, which claims better performance/scalability/maintanability uses c++ for lucene layer and java for the solr/elasticsearch layer. There are blog posts speeding lucene by 2x+ by changing some stuff to c/c++. There are libraries (trinity) claiming 2x+ performance . There is google-engineer saying "bigtable is 3x faster than hbase" that I've read.
itronitron 9y ago
People with an interest may want to check out Azul's Zing JVM and the following blog post testing it out with Lucene... http://blog.mikemccandless.com/2012/07/lucene-index-in-ram-with-azuls-zing-jvm.html http://blog.mikemccandless.com/2012/07/lucene-index-in-ram-w...

ndesaulniers 9y ago

> but allows the performance of ... malloc for key code paths. Everything is relative, I guess.

jakewins 9y ago
Hah :) I don't mean that malloc itself is fast, I mean that having non-jvm heap memory is fast. A permanent memory block on the JVM heap can't use pointers to refer to it, since GC moves objects around. And even though those blocks will never be collected, they make up additional work for the GC to track.