Lealone的过去现在将来
codefollower opened this issue · comments
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
特别好奇全链路异步化和基于SQL优先级抢占的实现思路和协议
2019/1/23 补充:
Lealone 目前已经是5.0了，前4代都没有正式发布过，5.0已经做好准备了，新增了列锁、page粒度的混合行列存储、异步化无锁B-Tree、统一异步任务调度器这几个超重量级的特性。
详情见: #22
@xch91
这是一个巨复杂的大工程，Lealone的单机版是从H2数据库演化来的，你有机会对比一下两者代码的巨大差异就知道了，Lealone是全异步的代表，H2刚好是传统的每连接对应一个线程的模型。现在忙着修bug，以后会写一些文章介绍。
最新的副本强一致协议能简单介绍下吗？有相关资料参考吗？ 多谢 @codefollower
有在生产环境运行的案例吗