由于工作关系,上司要每个月交一份小论文。这个月我分到了一个叫 KAI的数据库,分析下咯。
KAI
--by dp
概况
小日本写的一个nosql。很少人用,很少资料(一两篇日文文档),停止维护一段时间了(最后update时间是09年)。用Erlang编写,效率未知。
很少人使用,我个人就认为没有什么使用的意义,也不打算测试了,也不打算找资料了,分析一下它代码吧,当做练手erlang。本文就从它实现上和思想上分析一下。
技术层面一句话概况
模仿amazon 的Dynamo,提供memcached接口协议,用erlang编写的一个nosql。
源码分析
采用标准otp,模块分得有点细,模块独立性强。
从kai_sup.erl看出它所包含的模块。
kai_membership, kai_sync,kai_connection,kai_version,kai_stat, kai_store,kai_log, kai_config
时间有限,看到一个文件分析一个文件吧。它内部相互依赖不多。
kai_hash:
一看名字就知道它是实现Hash啦。跟Dynamo一样。Kai是用hash 环来实现数据冗余和定位,这个文件还实现了其他一些功能。
1、它实现的是32bit 的hash
2、虚拟节点
跟dynamo一样,支持虚拟节点,它是把虚拟节点的列表保存到ets中,截取增加虚拟节点一段看看,其实没什么亮点
3、bucket
Bucket信息也是存放在ets中。
关于bucket的选定。Kai定义了一样一条公式。为什么要这条公式我就不想深究了。
kai_memcache:
这个文件实现了memcached的通讯协议,通过socket,操作二进制流,实现的。这点得益于erlang的二进制操作的方便。是我见过最简洁的memcached协议实现了。
Kai的接口实现:
通过kai_tcp_server义了behavior。是基于gen_server的socket。kai_rpc则实现了kai_tcp_server,提供对外的接口。而kai_memcache 实现kai_tcp_server,提供memcached协议的接口。
Kai 内部数据流通讯:
由kai_connection。这个模块好玩。里面实现了节点间数据冗余的替换策略。
跟dynamo一样,采用LRU方式。
而节点的加入,离开都在这里处理。
总结
代码比tsung写得好,behavior的定义较为精巧。代码结构清晰。
但是个人认为的缺陷有几点:
1、 I/O的操作并没任何优化处理。直来直往,连接->ETS取路由信息->取数据返回。这样的数据库意义上只是在实现了memcached接口,并没有让kai发挥高性能的考虑。
2、 在数据唯一性方面,(由kai_version实现),有更新就广播所有节点,每个节点都要看看自己有没有这个数据,有就更新。而且如果同时更新一个节点时候,有点边界情况未有处理。