Open codefollower opened 7 years ago
特别好奇全链路异步化和基于SQL优先级抢占的实现思路和协议
2019/1/23 补充:
Lealone 目前已经是5.0了,前4代都没有正式发布过,5.0已经做好准备了,新增了列锁、page粒度的混合行列存储、异步化无锁B-Tree、统一异步任务调度器这几个超重量级的特性。
@xch91 这是一个巨复杂的大工程,Lealone的单机版是从H2数据库演化来的,你有机会对比一下两者代码的巨大差异就知道了,Lealone是全异步的代表,H2刚好是传统的每连接对应一个线程的模型。现在忙着修bug,以后会写一些文章介绍。
最新的副本强一致协议能简单介绍下吗?有相关资料参考吗? 多谢 @codefollower
有在生产环境运行的案例吗
Lealone不是一个市场驱动的投机产品,我更愿意把她看成是我将数据库和分布式系统两个领域融合后,进行基础理论研究和探索的试验品。目前已经到第5代了,前两代总体上是失败了,我可以再次回顾一下。
第1代
第1代仅仅是在HBase之上做分布式SQL引擎,当时我把H2数据库的单机SQL引擎改成分布式之后把HBase当成底层的分布式存储来用,同时用OMID解决分布式系统中与事务相关的所有问题,因为要依赖HDFS和ZK,整个架构涉及的组件太多,底层数据块隔得太远,对于索引的优化很难进行,挂了一个RS,可用性损失很大。
当然,因为HDFS已经帮你管理好数据块的副本问题了,这是好事也是坏事,好事是在HBase之上实现SQL和事务时都不用考虑多副本的问题,坏的一面就是我只能通过一个RS去读写某条记录,我想要更多的读写入口,做不到啊,所以HBase这种方案限制了很多想像力。
对于第一代失败的HBase尝试还是有收获的,比如让我学会了怎么把一条SQL重写后变成一条分布式SQL,让它能并行分发到HBase的不同RS上同时执行,当然,最重要的还是从OMID + HBase这种解决事务问题的方案中得到了新的灵感,让我找到了一个解决分布式事务问题的更好方案(这个就不展开了)。
第2代
第2代的焦点是放在模仿Cassandra身上的, Cassandra那样的架构消除了HBase所有的问题,组件少,每个节点都可以直接读写并且使用的是本地文件系统,所以索引想怎么玩都行。我当时并没有在Cassandra的代码上改造,只是拿了gms/net相关的代码,然后在分布式SQL引擎和H2的MVStore单机存储引擎之间用DHT做sharding。
第2代的最大问题其实也是Cassandra的最大问题,用DHT做sharding只适合做一些简单的单key查询,要按sharding key进行范围查询只能给集群所有节点都发查询请求了,哪怕只是个小范围的查询如果不拆开成多条sql也只能这么干。
对于一个分布式数据库来说,改动DHT这样的sharding算法是伤筋动骨的,Cassandra现在你让它去掉DHT改用HBase那种全局有序range的方案那是要命的,虽然它也有类似range的方案,但那是不能改的,没什么用。还好第2代的失败尝试过程中,又让我找到了新灵感,弄出了一种解决副本强一致性问题的新协议。
第3代
第3代摆脱Cassandra的思维定式后,就彻底解放了,脑洞大开,新的sharding算法不再像Cassandra那样放在SQL引擎和单机存储之间,而是下推到存储引擎内部,我引入了一种叫Leaf-Page-Sharding的算法,同时拥有DHT和range的优点。
第3代Lealone除了包含我原创的分布式事务模型、副本强一致性协议和Leaf-Page-Sharding算法外,当然还有其他很大胆的尝试,包括混合多种运行模式、全链路异步化、基于SQL优先级抢占、在对等架构中实现单表自增字段的全局有序单调递增(非常适合时序数据库的场景)。
第4代
第4代Lealone,换用一个高大上的名字就是“自治数据库”,不过我并不想扯上机器学习,而是从数据库现有的算法和数据结构着手,怎么让它们变得更灵活更动态,比如我最近在试验的消除单机、replica set、 sharding三种模式的差异就是往自治这个方向走。
第4代Lealone,除了优化数据库内部的实现外,我还做了大量能改变应用开发模式的疯狂尝试,从前端到后端应用服务器、web框架、ORM框架,甚至小到连接池这种东西,我都把它们考虑在内,哪些适合放到数据库解决的就干掉,不适合的也给他们提供便利。
第5代
第5代Lealone,新增了列锁、page粒度的混合行列存储、异步化无锁B-Tree、统一异步任务调度器这几个超重量级的特性。详情见: #22