标题是个噱头,这里只说积分数据全部装载到内存
首先,玩家的积分什么的有单独的表存储,这里不谈序列化,语言是C++
假定score是double,id是int64
然后计算空间需求,这里假设实现了专用无税收的内存适配器
32位进程大地址,每个节点32字节,4G的进程可以放下1.34亿的数据,去掉进程本身的边角,1.2亿
64位进程,每个节点48字节,1亿数据需要4.47G内存,根据需要自己给服务器加内存吧...
然后就没有然后了...
就是这么简单粗暴的把所有积分塞进内存
查询第k名玩家的id
查询积分n可以排多少名
好吧,存在的问题是,更新略恶心,用积分做k,存在相同积分时候,equal_range后遍历找到对应id,erase后重新insert吧
序列化什么的,可以考虑内存映射文件+对应内存适配器来搞定
然后说说容器本身!
自己码的sorted_set类,可随机访问的kv容器,std::multimap风格,允许重复key
operator[]操作不明确下标访问或是key-value查询,所以没有实现
内部二叉树结构,除了parent,left,right之外,只有一个SBT需要的size域,4个指针大小
随机访问迭代器,可以+/-/+=/-=操作,可以两个迭代器相减求距离
这里的rank从0开始,并没有给出select函数,而是参考std::vector使用at随机访问
各种接口的复杂度不超过O(log2n),参考陈启峰的size balanced tree
树结构还算平衡,顺序/乱序插入的时间开销是std::multimap的1.2倍左右,这里请教是不是我实现有问题?
最后念叨点题外的!
说起来个人比较懒...
最初是我的俄罗斯方块AI里面的需求,对有序的std::vector不断归并,std::merge成了性能瓶颈!
之后考虑节AI内部本身就是一个个节点,直接建立二叉树来排序效果应该不错,但是AI内部节点都是百万级别!
于是直接用std::map的问题就是new的时候会有税收,而且本身就是AI节点,所以参考std::map源码直接搞了个一个不去new节点,直接把外部节点挂在树上的容器!还没有clear开销!
似乎就是这样了,然而后来听说size balanced tree比red black tree性能还好,然后改造起来也不麻烦!索性顺手加上那个神maintain来测试一下性能~
结果实测,比红黑树稍慢,也可能是我的实现有问题?没有达到陈启峰说的超越红黑树,不过也算是一个数量级~
最终俄罗斯方块AI还是用了红黑树...
------分割线------
群里某人问:"SortedList相当于C++里的啥容器？"
于是我就把之前的外挂节点的容器拿来重构...
暂时叫sorted_set,跟redis的Z系列很像,同npm的sorted-set(内部跳表实现)
相比其他的rank tree实现,附加域没有任何浪费什么的太漂亮了
本文3个目的
1.安利一下size balanced tree
2.找高人看看我的实现有什么问题
3.抛砖引玉