数据库 – 使用CQL脚本的Cassandra Schema Management

致Cassandra专家:我的任务是提出有关Cassandra CQL脚本管理和部署的建议.团队如何管理(应该管理)大量的CQL脚本(模式定义脚本(DDL),数据操作脚本(INSERT / UPDATE / DELETE)从Cassandra开发的开始以及随后对应用程序模式模型的更改.如果可以的话,我想指出,开发团队的规模并不小(每个应用程序功能区域有10个开发人员).

一种方式(可能是错误的方式)是做典型的关系数据库商店会做的事情:app开发人员或开发dbas设计并创建ddl,dml等,脚本,在版本控制系统(例如SVN)中存储和维护它们,以及使用一些自动化(可能像shell或perl脚本一样简单)在环境(dev,qc等)中部署脚本.我认为在NoSQL解决方案中出现问题的地方如Cassandra是参与这三个步骤的演员.
1 – 设计和创建CQL脚本 – 应该由DevOps(cassandra管理员)还是应用程序开发人员完成?
(2)在SVN中存储和维护它们 – 如果这类似于上面的(1)和(3)脚本的部署 – 如果来自应用程序开发的人这样做(或)DevOps这样做吗?
我还想从应用程序模式控制和审计角度得到答案.例如,对于上面的#1和#2,如果应用程序开发人员在SVN中设计,创建和存储CQL脚本,那么如何能够控制进入CQL模式的内容并防止代价高昂的错误.如果有专门的单一团队拥有数据模型而不是所有cassandra开发人员(类似于DBA / Administrators),则更容易实现该控制.

我希望那些之前完成此任务的人能够深入了解大型环境中CQL代码开发,部署和维护的选择和最佳实践.
一如既往地谢谢.

最佳答案 我认为您将面临的主要问题是您需要编写代码来执行一些迁移,这与在典型SQL场景中应用增量补丁相比具有显着差异.可以使用DevOps / DBA样式中的cqlsh工具轻松应用模式的基本更改(使用CQL定义).这些类型的更改包括添加列和删除列.但是如果你需要做一些更基础的事情,那么你将不得不编写CQL客户端代码来迁移旧数据.对于您的应用程序所需的更多非规范化和非声明性索引,尤其如此.

FWIW和YMMV我能够自动化CQL模式管理的一个方面,即找到一种方法来保持模式和应用程序代码同步.为此,我编写了一个生成样板应用程序源代码的CQL schema compiler,以便数据绑定始终与Cassandra中的当前模式同步.但这只是整个问题的一个方面.

点赞