深入探索Lindorm兼容Cassandra CQL背后的故事

用户福利

阿里云最新发布业界首款云原生多模数据库Lindorm,帮助企业一站式存储处理海量数据,降低80%成本,技术交流钉钉群:35977898,更多内容请参考链接

一、背景

阿里云多模云Lindorm作为面向海量数据场景下的半结构化、结构化低成本存储系统,广泛服务着阿里巴巴集团内部和外部用户。Lindorm一直致力于"让企业数据存的起,看得见",并持续保持着快速的能力更新和技术升级。一方面,通过引入低成本存储池来降低单位存储成本,同时通过智能冷热分离技术感知用户数据热度,提升查询性能。另一方面,提供了丰富的全局二级索引和搜索引擎能力,并通过原生Lindorm API、HBase兼容API、兼容JDBC标准的Lindorm SQL查询方式暴露给用户。此外Lindorm作为云原生多模数据库,目前支持宽表、时序、搜索、文件等多种数据模型,各模型间数据互融互通,一处写入处处可读,以适应用户在不同场景下的需求,使应用开发变得更加敏捷、高效。更多有关Lindorm的相关介绍请参考存的起,看得见—云原生多模数据库Lindorm技术解析

Cassandra是一款开源NOSQL数据库,其设计和实现基于Google发表的bigtable 以及 Amazon 发表的Dynamo 论文。过去几年Cassandra 在开源社区受到大家广泛的喜爱,其对外提供了用户亲和的类SQL查询语言 CQL,并提供相对丰富的二级索引、检索、UDF/UDT/UDA等能力,具有很强的群众基础。

通过调研、分析与规划,我们决定去做Lindorm兼容Cassandra CQL这件事,那么当阿里云自研产品Lindorm遇到Apache*项目Cassandra,究竟会碰撞出哪些火花?

二、为何兼容

2.1.兼容的收益

2.1.1.用户的收益

通过调研Cassandra的相关功能和特性,发现部分特性可以为云原生多模数据库Lindorm的用户带来很多好处:
• CQL提高开发效率、优化使用体验
CQL 全称Cassandra Query Language ,是Cassandra社区为了更便捷的访问Cassandra而实现的一套类SQL的语言。熟悉SQL操作的同学可以轻松快速的学习CQL的使用。Lindorm兼容Cassandra后会给用户带来如下好处:
  1. 功能丰富:提供了丰富的数据类型(22种基本数据类型、集合数据类型、UDT等),丰富的功能入口 (DDL/DML/ACL)以及很多索引操作入口,提高开发效率;
  2. 理解容易:CQL完全开源,学习资料较多, 方便用户快速上手使用,降低学习使用Lindorm的门槛;
  3. 生态完善:Cassandra CQL客户端支持Python、Go、C++、Java、NodeJs、C#等多种语言,也能够支持多种框架比如spring、orm框架等,用户可以快速上手,便捷使用。
此外,CQL能够原生支持TTL,JSON等NoSQL特有的能力,很适合作为半结构化数据的统一查询语言,CQL语言的具体介绍可以参考CQL的具体介绍。兼容Cassandra CQL后,用户可以更高效的使用Lindorm,提高用户使用体验,降低Lindorm使用门槛。

• 丰富的功能不断满足日益增长的用户需求
除了CQL之外,Cassandra对外也暴露了丰富的索引能力:原生二级索引、SASI 索引、Materialized View以及近期实现的SAI,并具备UDT/UDA/UDF/Trigger等一系列用户自定义操作。在社区和商业公司的不断迭代下,Cassandra的现在具备的功能在一定程度上可以代表用户对NOSQL数据库需求的演进方向。Lindorm兼容Cassandra后,用户对存储、数据库产品的需求也可以持续被满足,从而简化用户侧技术架构复杂度。

Lindorm作为演进多年的云原生数据库,具备独特且先进的技术体系,通过兼容Cassandra,满足Cassandra用户的演进需求,会让云Cassandra用户以及其他Cassandra自建用户享受Lindorm带来的技术体验,那么对于云数据库Cassandra的用户来说,可以享受到如下技术优势:
 • 弹性优势
Lindorm 提供了任意规模的弹性能力(1MB-100PB,1tps-千万级tps),其核心源于Lindorm的池化的设计。通过存储计算分离技术实现对计算资源和存储资源的分别利用,再通过Serverless提供的技术逐步完善按需计费,多租户隔离/限流,从而实现智能的调度。而Cassandra基于本地盘的设计扩容成本较高,基于实例收费的方式门槛也较高。
 • 存储成本优势
Lindorm通过构建云原生存储LindormStore,借力OSS等低成本存储来降低存储成本,并利用云盘等高性能存储进行访问加速,此外Lindorm宽表引擎层通过高压缩编码、冷热分离手段也会降低用户存储成本。而Cassandra整体设计基于本地磁盘,很难借力云基础设施来降低成本。
 • 性能优势
经过云上和集团业务的多年的打磨,Lindorm在读/写性能、毛刺、数据压缩率等各方面指标均优于开源Cassandra系统,通过Lindorm兼容Cassandra的方式可以让更多开源用户以及非Cassandra用户享受到Lindorm带来的低成本、高性价比的技术红利。下图是吞吐量场景下,Lindorm 与 开源Cassandra的性能指标对比:
深入探索Lindorm兼容Cassandra CQL背后的故事

 • 生态工具优势
Lindorm提供了Lindorm Tunnel Service(原BDS)等组件,打通了与DB,ODPS,Kafka/MQ等阿里云生态体系的数据流转。同时通过与DataWorks,Blink,DLA等团队的深度合作,保证了用户的数据能够写的进,读得出。Lindorm兼容Cassandra可以避免为Cassandra重复造*,也可以方便云数据Cassandra的用户快速上手使用Lindorm完善的生态组件。

2.1.2.产品侧收益

Lindorm团队维护了多款云上数据库产品,通过Lindorm兼容Cassandra会给相关数据库产品带来很大价值增益。
 • Cassandra庞大的基础用户
在商业公司Datastax和开源社区的运作下,Cassandra积累了像苹果,华为等重量级客户,其在DB-Engines上的排名目前也位于宽表类第一名。据了解,DataStax 2019年营收超过10亿人民币。利用Lindorm的性能、成本和弹性优势,可以通过Lindorm兼容Cassandra可以方便吸收自建Cassandra的市场份额。
 • 优化使用体验,降低使用门槛
通过兼容Cassandra CQL,可以方便更多的用户便捷地使用Lindorm。Cassandra丰富的多语言客户端也可以满足不同语言体系的业务接入Lindorm平台。
 • 技术资源协调
通过Lindorm兼容Cassandra,打通底层技术,可充分提升云Cassandra产品的技术竞争力,并且通过复用Lindorm底层技术,降低内核层面技术重复投入。

2.2.可行性分析

通过对Lindorm以及Cassandra引擎实现、数据模型的设计对比,我们发现二者具备很多共通的特质,也正是这些共通的特质奠定了Lindorm兼容Cassandra的基础。
 • 数据模型
通过深入分析Lindorm 和Cassandra的数据模型,我们发现虽然二者在模型上存在细微的差异,但本质上都是KV模型,也就是一条Key 都会关联与之对应的Value。这样外部请求key,无论Lindorm还是Cassandra就可以返回所需的正确Value。
 • LSM-Tree base engine
Lindorm的多模引擎中宽表引擎以及Cassandra都是基于LSM-Tree思想进行引擎的设计和实现,所以2者的读写模块都会有共同的WAL/Memtable/SSTable模块参与,也会有类似的Compaction策略进行异步数据的合并。理论上在单机引擎的读写链路上是可以做到功能的兼容的。
 • Cassandra CQL 兼容
对于CQL来说,Cassandra是通过网络协议接收到Driver的String query语句,然后进行parse以及转换成所需的Statement,整个流程相对清晰且独立,如果在Lindorm层实现对应的网络协议以进行query语句解析,parse成Lindorm所需的QP层请求,那么对接CQL语言的解析以及转换理论分析是可行的。
 • Cassandra其他功能兼容
上面阐述了CQL语法的兼容,当一条CQL翻译成对应的请求以后会变成实际的功能诉求,包括索引查询、数据类型支持、trigger等,所幸Lindorm本身具备实现上述功能的能力且已经具备上述所述能力。所以CQL的具体功能兼容也是可行的。

三、如何兼容

3.1.设计理念

一模多端 :一处写入,处处可用。保证CQL 所有Driver、Phoenix Driver、HBase API、Lindorm API、 Lindorm SQL等多种访问方式的数据兼容性
协议级兼容:兼容社区Driver,不改一行driver代码就可以通过Cassandra客户端访问Lindorm
Cloud Native: 面向云基础设施设计,避免重复投入
深入探索Lindorm兼容Cassandra CQL背后的故事

3.2.技术架构

Cassanda CQL兼容有2方面需要考虑:1.CQL入口能力的兼容- Lindorm 对CQL语法的兼容;2.Cassandra CQL暴露的功能兼容。下面是实现细节:
深入探索Lindorm兼容Cassandra CQL背后的故事

CQL协议兼容
因为社区所有Cassandra Ddriver都必须遵守CQL binary protocol,Lindorm 服务端通过完全兼容CQL binary protocol (V4版本),保证了使用社区各种driver都可以与Server进行正常交互。driver和server层之间的初始化交互会有一系列协议请求,单次CQL请求是直接发送String类型的query语句到server端。所以对于binary 协议兼容主要在初始化长连接以及单次CQL请求2方面进行兼容,对此Lindorm 兼容Cassandra主要做了如下工作;
 • 初始化链接兼容
 • driver感兴趣event register;
 • 认证/非认证/SSL等操作注册;
 • 获取集群拓扑状态操作;
 • 获取链接节点schema信息;
 • 单次DDL、DML、ACL等操作

对于链接初始化外的其他session操作,driver在发送请求前不会进行任何处理,CQL会以String方式被发送到server端,Server端在接收到请求后会通过Lindorm Server实现的CQL Parser 转换成对应的结构化Statement并分派给引擎进行处理;

通过上述方式可以达到不需要修改社区driver任何一行代码,兼容掉社区支持的所有driver。用户可以直接使用社区多语言driver访问Lindorm。
在CQL的语法解析层面,Lindorm 兼容Cassandra 直接使用Cassandra 3.x 版本的Cql.g定义文件进行编译处理,CQL解析这块主要是使用antrl3进行基本parse,并在已有的CQL语法功能上进行lindorm语法的适配,具体技术细节本节不进行详细概述。

查询请求元信息维护
原有CQL binary protocol 中大部分的driver 会初始化链接获取得到集群整个拓扑状态,然后基于拓扑状态进行对应链接相关节点。具体查询时,再根据拓扑状态选择负载较低的Server进行查询。调研过程中,我们发现这种模式主要存在几个问题:
 • 网络打通复杂,客户端必须跟所有Server节点网络互通,跨VPC场景很难实现
 • 客户端过多时,服务端存在链接风暴,再Serverless场景下单一集群的客户端规模可能打到10w+,直连的方式意味着单一Lindorm Server的tcp链接数目会超过10w+。
 • 原有Cassandra的实现依赖Gossiper,存在信息传递的延迟

为此Lindorm做了两个较大的改造,第一是把全部的服务发现和Table源信息获取都整合到Lindorm内部进行处理,而不是类似Cassandra那种依赖单独Gossiper模块进行获取。第二是前端挂ALB方式,通过ALB进行连接分配和负载管理,一台客户端只挂一个长链接。这种方式能够更容易的支持复杂的网络环境,拥有更好的安全性,也更容易与现在Lindorm的云管控结合。

服务发现以及Table源信息放到Lindorm内部处理会带来的各个Server间schema信息存在mismatch的风险,相应的会在mismatch的节点上出现错误编译的可能。这里我们在每个节点添加了异步缓存,缓存会定时load获取schema的Meta信息,每次查询的结果会比较表引擎层面的Meta版本和缓存的版本是否一致。对于未缓存的Meta或者版本不一致的Meta,Server会直接重新加载,保证了源信息获取的正确性以及请求的高性能。

功能支持
通过兼容CQL binary protocol 以及 实现CQL Parser,Lindorm能够无缝对接用户的CQL请求,例如:DDL/DML/ACL操作;对于功能层面,Lindorm 原生支持二级索引以及具备检索能力,通过CQL的吐出可以释放相关能力。

四、竞品对比

4.1.整体介绍

业内除了原生Cassandra之外,有AWS KeySpace、ScyllaDB、华为云GaussDB(for Cassandra) 等都是兼容或者翻译了Cassandra。
AWS Keyspace是基于AWS公有云平台实现的serverless场景下的Cassandra托管服务,通过对外的文档看到其兼容了大部分的Cassandra的功能,选择性的实现了DDL&&DML,但原有Cassandra的ACL被完全抛弃,改用AWS自己的IAM方式。

ScyllaDB则是号称C++版本的Cassandra,主打性能优势,兼容性实现的相对完善。古语云,学我者生,似我者死,尽管ScyllaDB拥有跟Cassandra极其相似的设计、很好的兼容性和纸面上很高的性能,但其并没有获得很好的市场认可。ScyllaDB依旧继承了Cassandra弹性不足,一致性保障较弱的缺点,Quorum Read的理念看似美好,也带来了为了弥补副本一致性而进行的row-level repair的资源开销。

反观Lindorm兼容Cassandra,基于Lindorm内核实现的CQL语言以及兼容的Cassandra功能,可以做到对Cassandra的高度兼容,满足用户全部常用需求,主要包括DDL&&DML&&ACL&&Data Type。更底层Lindorm是以统一存储、统一查询、多模引擎的架构进行全新升级,借助云基础设施红利,重点发挥云原生弹性、多模融合处理、极致性价比、企业级稳定性的优势。避免了Cassandra原生架构设计上的缺陷。

4.2. 对比列表

下述各项Cassandra功能支持对比 基于Lindorm2.2、Cassandra 3.11.4、AWS Keyspace(无版本信息暴露)、ScyllaDB(开源版本4.1.5),包括内测中的功能,Lindorm兼容Cassandra CQL 对 CQL 的兼容可达到90%以上。
API 支持

选项 Apache Cassandra Lindorm 兼容Cassandra CQL AWS Keyspace ScyllaDB
CREARE KEYSPACE YES YES YES YES
ALTER KEYSPACE YES YES YES YES
CREATE TABLE YES YES YES YES
ALTER TABLE YES YES YES YES
DROP KEYSPACE YES YES YES YES
DROP TABLE YES YES YES YES
SELECT YES YES YES YES
INSERT YES YES YES YES
UPDATE YES YES YES YES
DELETE YES YES YES YES
UPDATE YES YES YES YES
USE YES YES YES YES
TRUNCATE YES YES NO YES
UNLOGGED BATCH YES YES(内测中) YES YES
LOGGED BATCH YES YES(内测中) NO YES
CREATE INDEX YES YES(内测中) NO YES
DROP INDEX YES YES(内测中) NO YES

数据类型

选项 Apache Cassandra Lindorm 兼容Cassandra CQL AWS Keyspace ScyllaDB
bigint YES YES YES YES
blob YES YES YES YES
boolean YES YES YES YES
double YES YES YES YES
float YES YES YES YES
int YES YES YES YES
smallint YES YES YES YES
text YES YES YES YES
ascii YES YES YES YES
counter YES YES YES YES
date YES YES YES YES
decimal YES YES YES YES
inet YES YES YES YES
collection type YES YES(内测中) YES YES
time YES YES YES YES
timestamp YES YES YES YES
timeuuid YES YES(内测中) YES YES
uuid YES YES NO YES
duration YES YES YES YES

产品形态

选项 Apache Cassandra Lindorm 兼容Cassandra CQL AWS Keyspace ScyllaDB
集群版 YES YES NO YES
serverless NO YES YES NO

五、总结

通过兼容Cassandra CQL,Lindorm用户可以使用各种多语言的Driver以CQL的方式访问Lindorm,使用体验会变的更加亲和以及流畅,并降低用户的学习成本,方便SQL用户低成本迁移。对于Cassandra的用户,可以做到无缝迁移Lindorm,利用Lindorm 提供的冷热分离技术,依赖低成本云原生LindormStore来降低数据库的成本。对于其他用户,无论是使用Lindorm集群版还是Lindorm serverless版,兼容Cassandra都会提供一种新的数据库的使用选择。

Lindorm兼容Cassandra CQL,向上通过CQL作为Lindorm 的主入口,处理NOSQL用户TP场景下的读写请求,此外也可以通过CQL释放Lindorm以往积累的各种黑科技,比如智能化冷热分离、高效检索能力。向下Lindorm也会持续吸收优秀的、广泛用户需求的功能点,集百家之长。

六、未来计划

未来Lindorm兼容Cassandra CQL主要工作会聚焦于“向下兼容、向上扩容”的宗旨。向上,要能够支持CQL以及其他查询语言比较优秀的功能点,如聚合操作、User Defined Function/Type等。向下,要将Lindorm自身能力更好的暴露出去,比如Serverless,LSearch,冷热分离等核心能力将会通过CQL暴露出去。

上一篇:sql创建临时表或视图增加 自增列


下一篇:会SQL,就会用Lindorm