mapdb 开源包踩坑小记

我开发的产品的模块中，近期增加了一个“日志索引”功能，用于快速在多个大文件中定位运行日志。

找到一个关键模块的开源软件 mapdb，这是一个好东西啊

将map的快速与持久化（或半持久化）功能融合在一起，就是一个JAVA嵌入式的 Redis

mapdb与Redis区别：

Redis也能完全相同的工作，但必竟其独立于JVM之外通过Socket交互，能达到10万次/秒就很不了不起了

mapdb可直接嵌入到JVM运行空间，运行效率是Redis没法比的，单线程能达到 30万次/秒


mapdb的使用场景：

1、用于JVM内部的缓存，全内存操作，在标准Java map的基本上，增加过期时间、大记录数等限制

2、用于将Map中的内容持久化，可调用 db.commit()提交到文件

3、用于大量map数据的持久化或半执久化（提升性能）

本系统中用于日志索引的数据即为半持久化操作，每分钟提交一次即可，中间丢一部份数据也无所谓，设计上下次会进行“断点继续”


本次从mapdb.org发布网站上下载了新的版本，性能测试了一下，很，API也比较人性化。


遇到问题：

集成到本系统中后，日志索引功能运行正常，对增量的日志建索引也比较快，每秒处理日志量 150M

在系统做了其它多个功能模块修改后，后集成的版本在日志索引这块运行有问题：

每次启动时，mapdb模块报异常:

java.lang.ArrayIndexOutOfBoundsException: 2
at org.mapdb.StoreDirect.recidToOffset(StoreDirect.java:1639)
at org.mapdb.StoreWAL.get2(StoreWAL.java:450)
at org.mapdb.Store.get(Store.java:253)
at org.mapdb.HTreeMap.recursiveDirCount(HTreeMap.java:529)
at org.mapdb.HTreeMap.sizeLong(HTreeMap.java:500)
at org.mapdb.HTreeMap.size(HTreeMap.java:471)
at net4j.util.LogUtil.checkLogIndexDB(LogUtil.java:123)
at net4j.util.LogUtil.getInstance(LogUtil.java:109)
at net4j.tools.Net4jAdmin.main(Net4jAdmin.java:80)
即：获取上次持久化的数据出错

将自己写的代码多处优化后，还是报类似的错误！

虽然日志索引模块的处理有多个线程完成，但也不应该在mapdb这个处理点上报这个错误，它不是号称支持100G以上数据，支持多线程嘛？我这个才几M数据而已。

系统代码多处修改无果， 后想着是否这个 mapdb 模块本身有问题？


解决过程：

写了2个专用于验证 mapdb的小程序，模拟本系统的使用场景进行“简化操作”。

问题找到了！

程序写1000条记录没问题，1万、10万都没问题，100万条记录-----故障重现了！！太好了，能小化用例重现故障，解决起来就方便多了。

故障分析：

mapdb这个模块，应该是一个稳定的库，个人还是比较相信老外开源组织的能力及责任心，即然已确定是mapdb本身的问题，而且这么大一个BUG，其它人难道就没发现并提交开源小组修正？

仔细看了一下我下载的版本，v2.0.0Beta 11 ---- 是否可能是Beta版本的缘故？

再次下载其稳定的发布版 V1.0.9 Release，发现旧版的API与新版有较大不同，修改代码适应它，再次验证100万笔----不出所断，稳定版本该功能是OK的



故障小结：

1、下载开源软件时，避免下载未发布的Beta版本，尤其是大版本有不同的开源包，大版本不同往往开发者对数据结构做了较大的调整，但还在不断完善过程中。

2、出现故障时，在简单的排查找不到故障原因时，必须使用“简测试用例法”，将无关的处理逻辑能去除的都去除，只留下故障模块相关的部分或重新用例，用于验证故障，此时故障更容易发现并解决

3、作为架构师，在排查此类故障时，必须要有足够的耐心，有时查一天两天也是正常的，架构师就应该在不断思考和调整，寻找可靠性、成本、扩展性、安全性、性能等综合比较好的方案，来优化和升级现有系统，进而不断的迭代，不断反思曾经犯过的错误，这样一步步成长起来的。


小计:

mapdb1.0与2.0在处理性能上还是有比较大差距的。

同样的批量写入，2.0能达到30万记录/秒，1.0约为7万记录/秒，正如开发者blog中所说，有4倍性能提升。

等到2.0版本正式发布，我的系统中还是会切到2.0版本。



我开发的产品的模块中，近期增加了一个“日志索引”功能，用于快速在多个大文件中定位运行日志。

找到一个关键模块的开源软件 mapdb，这是一个好东西啊

将map的快速与持久化（或半持久化）功能融合在一起，就是一个JAVA嵌入式的 Redis

mapdb与Redis区别：

Redis也能完全相同的工作，但必竟其独立于JVM之外通过Socket交互，能达到10万次/秒就很不了不起了

mapdb可直接嵌入到JVM运行空间，运行效率是Redis没法比的，单线程能达到 30万次/秒


mapdb的使用场景：

1、用于JVM内部的缓存，全内存操作，在标准Java map的基本上，增加过期时间、大记录数等限制

2、用于将Map中的内容持久化，可调用 db.commit()提交到文件

3、用于大量map数据的持久化或半执久化（提升性能）

本系统中用于日志索引的数据即为半持久化操作，每分钟提交一次即可，中间丢一部份数据也无所谓，设计上下次会进行“断点继续”


本次从mapdb.org发布网站上下载了新的版本，性能测试了一下，很，API也比较人性化。


遇到问题：

集成到本系统中后，日志索引功能运行正常，对增量的日志建索引也比较快，每秒处理日志量 150M

在系统做了其它多个功能模块修改后，后集成的版本在日志索引这块运行有问题：

每次启动时，mapdb模块报异常:

java.lang.ArrayIndexOutOfBoundsException: 2
at org.mapdb.StoreDirect.recidToOffset(StoreDirect.java:1639)
at org.mapdb.StoreWAL.get2(StoreWAL.java:450)
at org.mapdb.Store.get(Store.java:253)
at org.mapdb.HTreeMap.recursiveDirCount(HTreeMap.java:529)
at org.mapdb.HTreeMap.sizeLong(HTreeMap.java:500)
at org.mapdb.HTreeMap.size(HTreeMap.java:471)
at net4j.util.LogUtil.checkLogIndexDB(LogUtil.java:123)
at net4j.util.LogUtil.getInstance(LogUtil.java:109)
at net4j.tools.Net4jAdmin.main(Net4jAdmin.java:80)
即：获取上次持久化的数据出错

将自己写的代码多处优化后，还是报类似的错误！

虽然日志索引模块的处理有多个线程完成，但也不应该在mapdb这个处理点上报这个错误，它不是号称支持100G以上数据，支持多线程嘛？我这个才几M数据而已。

系统代码多处修改无果， 后想着是否这个 mapdb 模块本身有问题？


解决过程：

写了2个专用于验证 mapdb的小程序，模拟本系统的使用场景进行“简化操作”。

问题找到了！

程序写1000条记录没问题，1万、10万都没问题，100万条记录-----故障重现了！！太好了，能小化用例重现故障，解决起来就方便多了。

故障分析：

mapdb这个模块，应该是一个稳定的库，个人还是比较相信老外开源组织的能力及责任心，即然已确定是mapdb本身的问题，而且这么大一个BUG，其它人难道就没发现并提交开源小组修正？

仔细看了一下我下载的版本，v2.0.0Beta 11 ---- 是否可能是Beta版本的缘故？

再次下载其稳定的发布版 V1.0.9 Release，发现旧版的API与新版有较大不同，修改代码适应它，再次验证100万笔----不出所断，稳定版本该功能是OK的



故障小结：

1、下载开源软件时，避免下载未发布的Beta版本，尤其是大版本有不同的开源包，大版本不同往往开发者对数据结构做了较大的调整，但还在不断完善过程中。

2、出现故障时，在简单的排查找不到故障原因时，必须使用“简测试用例法”，将无关的处理逻辑能去除的都去除，只留下故障模块相关的部分或重新用例，用于验证故障，此时故障更容易发现并解决

3、作为架构师，在排查此类故障时，必须要有足够的耐心，有时查一天两天也是正常的，架构师就应该在不断思考和调整，寻找可靠性、成本、扩展性、安全性、性能等综合比较好的方案，来优化和升级现有系统，进而不断的迭代，不断反思曾经犯过的错误，这样一步步成长起来的。


小计:

mapdb1.0与2.0在处理性能上还是有比较大差距的。

同样的批量写入，2.0能达到30万记录/秒，1.0约为7万记录/秒，正如开发者blog中所说，有4倍性能提升。

等到2.0版本正式发布，我的系统中还是会切到2.0版本。
————————————————
版权声明：本文为CSDN博主「turandot」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/laotian/article/details/50386212