既然要考虑为什么使用，那么我们应该从这么几点来去分析这个问题。
1、原始需求是什么？
2、现有框架/产品。
3、对比匹配一个。
原始需求是什么？
功能方面:
一、需要存储6种格式的数据
1、client_session_subscriptions
包含clientid、订阅主题、订阅主题质量、更新时间
2、client_sessions(客户端连接信息)
包含是clientid、否在线、在线node、持久化session选项
3、outgoing_message_flow(服务端发送给客户端信息流水)
包含clientid、message(即所有从服务端到客户端的mqtt消息)、时间戳
4、incomming_message_flow（客户端发送给服务端信息流水）
包含clientid、message(即所有从客户端到服务端的mqtt消息)、时间戳
5、queued_messages(服务端向客户端发送消息的队列)
包含clientid、publish、时间戳
三、支持Transaction
四、因为HiveMQ自己做的Cluster Replicate,所以embedded数据库更佳。
性能方面:
1、在完成高性能的同时需要满足占用很少的消耗，尤其是内存。
现有框架/产品
redis
功能
1、Key-Value内存数据库
2、不支持Transaction
3、非embedded
性能
1、连接占用tcp连接
2、占内存
3、并发读写性能很好
MapDB
功能
1、embedded
2、纯java编写，适合HiveMQ调用
3、支持Transaction
4、B-Tree
性能
该处性能由于有Xodus做的性能对比，此处不做赘述。
H2 MVStore Map
功能
1、Key-Value数据库
2、支持Transaction
3、R-Tree
4、非embedded
性能
该处性能由于有Xodus做的性能对比，此处不做赘述。
Xodus
功能
1、支持Transaction
2、embedded
3、MVCC
性能
该处性能由于有Xodus做的性能对比，此处不做赘述。
对比匹配一个
功能
由于HiveMQ存储结构较简单、单一；不需要太丰富的查询、插入；支持事物；并最好是embedded型数据库即可，所以由上即可选出使用MapDB和Xodus。
题外话：在3.x.x版本之前，hivemq就是采用MapDB做为持久化框架。
之后hivemq在性能、并发性做了非常大的调优。
性能
下图为xodus官网给出的性能对比:
对比
xodus源码地址:https://github.com/JetBrains/xodus
总结
由上分析，我们就可以得出今天最终的答案。
HiveMQ的性能测试如下:
链接: https://pan.baidu.com/s/1gfHsKkN 密码: 9fhk
