Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lealone的过去现在将来 #16

Open
codefollower opened this issue Nov 8, 2017 · 5 comments
Open

Lealone的过去现在将来 #16

codefollower opened this issue Nov 8, 2017 · 5 comments

Comments

@codefollower
Copy link
Owner

codefollower commented Nov 8, 2017

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

@alyoshark
Copy link

特别好奇全链路异步化和基于SQL优先级抢占的实现思路和协议

@codefollower
Copy link
Owner Author

2019/1/23 补充:

Lealone 目前已经是5.0了,前4代都没有正式发布过,5.0已经做好准备了,新增了列锁、page粒度的混合行列存储、异步化无锁B-Tree、统一异步任务调度器这几个超重量级的特性。

详情见: #22

@codefollower
Copy link
Owner Author

@xch91
这是一个巨复杂的大工程,Lealone的单机版是从H2数据库演化来的,你有机会对比一下两者代码的巨大差异就知道了,Lealone是全异步的代表,H2刚好是传统的每连接对应一个线程的模型。现在忙着修bug,以后会写一些文章介绍。

@codefollower codefollower changed the title Lealone过去现在将来 Lealone的过去现在将来 Sep 22, 2019
@hustnn
Copy link

hustnn commented May 12, 2020

最新的副本强一致协议能简单介绍下吗?有相关资料参考吗? 多谢 @codefollower

@caojiajun
Copy link

有在生产环境运行的案例吗

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants