开发者畅想 | openGemini 路在何方?

原创
01/19 15:08
阅读数 18

我们一直致力于让openGemini实现更快、更省、更强的目标,面对技术挑战,我们积极突破,逢山开路,遇水搭桥,持续提升软件质量,以满足社区用户和市场的需求。我们夜以继日,持续改进,希望为国家基础软件贡献自己的一点力量。人的一生是短暂的,作为软件工程师,希望我们开发的软件,具备很高的使用价值,被行业认可,推动社会向前发展,这就是我们这群人做开源最大的意义。

尽管我们大方向是向前,但我们也需要不断地进行微调,因为行业在不断地变化,应用场景和技术在不断变化,我们也需要适应这种变化,以便做得更好。因此,本期不探讨详细的技术,只是简要地谈论一些近期openGemini关注的方向和对社区的思考。

Serverless

今年,各大云厂商和数据库厂商都在积极拥抱 serverless 技术,因为在降本的大背景下,serverless 可谓是一大利器。对企业来说,能提高资源利用率,减少资源的闲置,对用户来说,它不仅可以减轻运维负担,还可以根据需求进行扩缩容,实现人力和资源的双重降本,这是云计算的独特优势之一。

关于马斯克的 Twitter 下云新闻,确实降低了云成本,但并未提到线下成本的变化。这就像是一个人吃了一种药,只说吃了这种药,但没有说吃之前和之后的病情变化。虽然整体成本可能有所下降,但我们不能忽视在这个过程中可能引发的问题,比如 Twitter 在迁移过程中出现的各种 bug, 以及其他厂商可能出现的不稳定问题。

不管怎么说,serverless将会是未来的趋势,随着技术不断改进,成本只能越来越低。

回到正题,关于是否要上云,关键在于综合考虑设备成本、资源利用率、人力成本和可靠性等因素。如果这些因素超过了可接受的那根线,那么就可以自行运维,否则就需要上云。今年,我们在 serverless 领域做出了一些探索和改进,包括增加了读写分离,解决了之前读写相互影响的问题,并实现了更精细的资源控制和更高效的资源利用。由于 serverless 是云原生的特性,我们无法在社区中分享这些特定的资源控制功能,但预计这些功能将在未来的社区版本中得到体现。

图片来自于 https://www.atatus.com/blog/the-serverless

Apache Arrow

我们早在几年前就开始探讨这个问题。在过去的一年中,我们在一个使用 Python 开发的分析型项目中使用了 Apache arrow,,并初步获得了一些增益。由于跨语言传输对象和序列化反序列化开销较大,使用Arrow后效率提升了不少。但是我们也发现了一些不便,例如无法修改,需要封装才能更好地使用。今年,在华为云内部的一个场景给openGemini提出了新的技术挑战,在限定资源的情况下,写性能要满足百万级/秒的写入性能,因此我们把Arrow重新提上了日程。这对其他应用来说,本身就是列存格式的或者兼容Arrow,写性能有极大的提升,否则需要对格式做一定的转换,存在一定的开销。我们将会在性能和易用性之间寻求平衡,这个平衡点的把握交给了自研SDK。

图片来自于https://blog.devgenius.io/apache-arrow-2d72137d9e84

分级存储

分级存储的本质也是为了降低成本。这主要依赖于一个假设,即随着时间的推移,老的数据的价值会逐渐降低,被访问的频次也会降低。在这种情况下,我们可以通过降低存储精度或者将数据转储到更便宜的存储介质上。

从另一个角度来看,对于那些价值高、访问频次高的数据,我们可以将其分散存储,以分散压力,使多个节点能够承担更高的 QPS。IO和CPU是影响QPS重要的两个因素,如果是 IO导致的,分级存储可以通过将热数据做厚,缓存更多的热数据。如果是CPU导致的,可以通过预处理、算子下推,减少计算的数据量,一定程度上能解决CPU问题。

总的来说,分级存储就是将数据存储做到更加聪明,更加智能。

几年前,当openGemini还在规划阶段时,有一个外部客户向我们咨询时序数据库的推荐。当时,环顾四周,寻找社区版可用的分布式时序数据库,发现Victoria Metrics是唯一一个可行的选择。虽然该数据库的降采样功能只在企业版中才有,但是历史数据太多,直接删除也不是一个好的选择。遗憾的是由于经费的限制,他们最终只能缩短不重要业务数据的老化时间。面对这些市场痛点,openGemini社区版本果断支持分布式、降采样等刚需特性。至于分级存储,这是一种适用于云特性的方案,对于线下场景,实现难度很大。

图片来自于https://www.modb.pro/db/171739

开源社区

建立社区是一件重要的事情,它能够倾听更多的声音,吸收更多的优秀人才,并为内外部的同学提供展示自己的机会。开源一年多时间来,参与社区的人数越来越多,用户也越来越多,社区逐步转向开放。然而,社区的发展不能只此而已,我们需要更加开放、活跃和深入,需要更多的人加入。

回忆起过去,当我还是一名数据库运维开发小兵,很痛苦,遇到问题就很痛苦,产品选用了某开源数据库,常常出了问题束手无策,无法把握住自己的命运,好在组织还是比较重视,顶不住了,批了一万美刀经费请官方技术顾问,一天一千刀,搞了几回,收敛了问题,但对其原理,一直不甚清楚,要是再出问题,还得花钱消灾。

关于这点,我强烈建议有能力的企业一定要参与到社区来,共同把握社区的技术方向和产品定位,坦白讲,数据库内核不简单,有门槛,但仅限于从零开始做。openGemini已经是一个技术比较成熟的数据库,剩余工作主要是新增功能、修复Bug、性能优化、以及易用性工具和技术生态。这些工作,我们团队的实习生,一个月就可以上手,其实并不难。后续我也会总结一些问题定位方法和工具分享给大家,遇到问题可以不用慌。

图片来自于CCF:https://www.ccf.org.cn/Activities/ConferenceS/CTO_Club/NEW/2021-06-23/730635.shtml

总结

小结一下,作为社区的一员,简述了个人在一些技术方面的思考以及开发生涯中穿插的小故事。希望以这种方式,激发大家踊跃参与到社区以及得到大家醍醐灌顶的吐槽指点。


openGemini官网:http://www.openGemini.org

openGemini开源地址:https://github.com/openGemini

openGemini公众号:

欢迎关注~ 诚邀你加入 openGemini 社区,共建、共治、共享未来!

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部