内存数据库索引

　　记得早前第一份工做的时候，很得意本身能写很是庞大的存储过程，聊起天来就是怎样引用索引、怎么写sql快；想一想那时候多好，容易知足，容易开心，开怀大笑！

　　仍是在前年的时候，忙完一个大项目以后！恰好有点时间研究fastdb，由于早期没用商用数据库以前就是用的这个。后来发现并发能力的问题，才切换到商用数据库。

　　若是单从数据读写能力来看，fastdb无疑具备很是强的竞争力；我记得几年前测试fastdb查询能力就比timesten的速度快很是多，可是关键在于fastdb在进程并发的时候就变的很慢。由于fastdb并非行级锁，而是表锁+库锁，多进程时候冲突增长的状况下性能跟不上。

　　fastdb有两种索引，hash索引和T-tree索引。

　　hash索引采用分桶的方式，数据和分桶数达到必定比例就重新分配桶，以保证hash结果能获得一个比较精确匹配的值，这样才能保证hash索引的效率。他的实现其实和stl里面的hash实现基本同样，我以为它的缺点和优势都很明显：

　　a、若是数据不能保证key是惟一的，那么大量的重复key将会致使hash性能直线降低

　　b、上述缺点其实也是优势，若是能保证key惟一。那么hash效率无疑比较好的算法选择

　　c、hash重新分配桶的时候，性能明显变慢。并且其占用空间也比较大

　　我今天主要是要记录关于T-tree索引的理解。11年的时候刚开始接触内存数据库，开始在网上搜相关资料，很惊奇的发现大量的文章在论证为什么内存数据库用的是T-tree而传统的物理数据库用的是B+tree。依据主要是如下两点

　　a、不少的文字在描述T-tree的效率理论上就比B-tree要高，虽然时间复杂度都是log2n，但那是基于时间复杂最坏打算来讲的；而数据库索引T-tree查询只有一半的几率查询须要到最坏状况，并且一半状况下能够提早查询到结果。

　　b、物理数据库选择B+tree一个重要缘由是磁盘换入换出，而内存数据库不存在这种需求。

　　不知道是否是基于这个理论，当时我所接触的几个数据库都是采用了T-tree索引，timesten、altibase、fastdb等几个无一例外。

 

　　等到前年去尝试改造fastdb的时候，把数据库改为行级锁，其中重要一部分就是T-tree索引的支持。基于上述理论，我开始不断的coding+test，很长一段时间都没有获得理想结果。其中我以为最难解决的问题是，T-tree索引在插入一个数据以后，节点分裂没法控制其父节点影响的层次。这种状况下，我只能无限的递归去锁定上层节点父节点，最终锁定的你会发现是跟节点，因此我想这就是当时fastdb为什么只能作到表锁的根本缘由。

　　我没法肯定timesten这些公司的人是怎么实现这种状况下的并发，除非他们有大量的松耦合逻辑来辅助这颗索引树来完成互斥的功能。

　　很幸运公司来了一个韩国数据库的团队（听说是大佬从altibase挖出来的核心团队）来交流产品，更幸运的是领导让我来接待他们，陪他们测试和交流技术，跟咱们在用的timesten进行了对标。他们总结的优点在于：

　　一、国产的，虽然是棒子作的。可是boss是中国大佬（那时候恰好掀起去IOE的风潮）

　　二、性能高，比市面上的主流数据库产品性能都高。还有一大批的性能对比测试报告（至关专业）

　　三、复制代理性能高，基于他们高速网络框架可以实现实时的数据同步。（有接触太高可用产品的人都知道，这一点相当重要。可是不能肯定他们是否是吹的）

　　另外，他们不否定的一个点是，如今市面上商用少，说国内有一个金融产品的点；主要仍是在韩国用。

　　基于他们说的这些，咱们进行了一些测试。基于这些测试数据，却是对他们产品有一些了解。首先是并发性能好，对比timesten彻底不是一个等级的，在3个进程之内，二者持平，可是进程数越多就越明显。后来我和他们来的韩国专家（固然有翻译，彻底装不起来B）交流，他们用的是B-tree，我问他怎么不用T-tree。棒子专家说了足有半小时，可是翻译兄弟给个人结果是：他们原来用的是T-tree，后来改为B-tree了，他们有从来的测试报告。至于缘由，翻译兄弟说他翻不过来了。。。后来还叨叨了不少其余的，通过翻译兄弟的嘴以后，索引互斥锁、复制代理啥的。感受收获很少（语言过重要！！）

　　通过此次交流，开始从新审视两颗树的差别，发现其实T-tree在索引更新时搞不定的问题用B-tree彻底能够解决。由于B-tree在分裂的时候，没有旋转的概念，并且他能够肯定分裂节点的父节点以上就不须要变动，基于这点就能够实现B-tree的互斥索引了。

　　因而我另外有一个发现，timesten11版本已经把T-tree索引改为了B-tree索引，并且新的内存数据库像sqlite也用的是B-tree。可是网上很难找到相关的论证文章。

　　不过无论如何，那时候已经决定从T-tree改为B-tree了，又开始了一个周期的coding+test。不断的修改和测试，这个小小的B-tree已经为我搞定了行级索引锁的问题测试了几百万数据，几个进程并发的状况下，3w/s的插入，查询20w+/s。。问题仍然存在，性能太差了。可是能帮我验证写的其它数据库管理代码，索引确实是个问题，但愿后面能找到其它灵感吧