用户福利

阿里云最新发布业界首款云原生多模数据库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提供了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： 面向云基础设施设计，避免重复投入

3.2.技术架构

Cassanda CQL兼容有2方面需要考虑：1.CQL入口能力的兼容- Lindorm 对CQL语法的兼容；2.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 支持

• 数据类型

• 产品形态

五、总结

通过兼容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暴露出去。