Jermy的专栏

hugegraph core性能优化 - 提升插入速度35%背景HugeGraph是一个Java语言编写的图数据库，也是开源的项目，本文记录了一次HugeGraph早期优化性能的过程分析与结果。HugeGraph之前使用Cassandra后端时，插入数据基本上90%时间花在写数据库操作上。随着后端存储RocksDB性能的不断优化（目前已达到 12w edges/s），HugeGraph在插入数据时core本身所占时间比重越来越大，因此core本身性能的优化又一次提上日程。如何优化性能？大体步骤

SOFA-RPC使用自定义类型数组参数报错：argument type mismatch1 问题表现2 问题定位分析1 定位客户端在发送数据之前是否有问题2 定位服务端接收到的数据是否有问题3 定位服务端处理数据是否有问题3 临时解决方法1 将RPC方法参数由`Id[] ids`改为`Object[] ids`，经过验证没有问题：2 或者将Id由`interface`改为`class`，经过验证也没有问题，但是由于需要修改大量已有代码，所以没办法实际应用，仅为测试该方案可行性：1 问题表现客户端通过RP

大规模数据OLAP分析爆内存问题分析与解决PR地址：Fix RocksDB OOM #823问题背景问题表现在执行如下Gremlin语句时，如果一次查询分析的结果数据在千万条以上，进程内存在几分钟内暴涨，JVM老年代占据将近20G内存、RocksDB占用本地内存超过100G，最终导致OOM，甚至进程被系统kill掉。g.V().hasLabel('vbsku').count() g.V...

堆内缓存：LinkedHashMap：Java自带类，内置LRU驱逐策略的实现（access-order）；多线程访问需要自己实现同步。Guava Cache：Google Guava工具包中的缓存实现，支持LRU驱逐策略；支持多线程并发访问，支持按时间过期，但只有在访问时才清除过期数据。Ehcache：支持多种驱逐策略：LFU、LRU、FIFO，支持持久化和集群。性能跟Guava Cac...

表现：通过JNI打开RocksDB报错：snappy压缩库没有被链接：org.rocksdb.RocksDBException: Compression type Snappy is not linked with the binary. at org.rocksdb.RocksDB.open(Native Method) ~[rocksdbjni-6.6.0-fix-osx.jar:?] ...

Cassandra的4种超时参数汇总read_request_timeout_in_ms、write_request_timeout_in_ms、SocketOptions.setReadTimeoutMillisSocketOptions.setConnectTimeoutMillisStatement.setReadTimeoutMillisrequest timeout

Java SPI机制实现插件化扩展功能。我们有一个图数据库的服务，用户希望在不修改现有源代码的情况下扩展自定义的分词器，达到可插件式扩展功能的目标。通过Java的SPI机制实现插件式的扩展功能还是比较简便的。特别的，在实现过程中遇到一个比较怪异的问题：ServiceLoader.load()时抛出NoClassDefFoundError，文末会记录一下这个问题的解决过程及原因分析。