database - 使用 CQL 脚本的 Cassandra 模式管理

Question

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

一种方法(可能是错误的方法)是做典型的关系数据库商店会做的事情:应用程序开发人员或开发 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/管理员)，则更容易实现该控制。

我希望以前做过这件事的人能够深入了解大型环境中 CQL 代码开发、部署和维护的选择和最佳实践。一如既往的感谢。

Answer 1

我认为您将面临的主要问题是您需要编写代码来执行一些迁移，这与在典型的 SQL 场景中应用增量补丁有很大不同。可以使用 DevOps/DBA 样式的 cqlsh 工具轻松应用对架构(使用 CQL 定义)的基本更改。这些类型的更改包括添加列和删除列。但是，如果您需要做一些更基础的事情，那么您将不得不编写 CQL 客户端代码来迁移旧数据。当您的应用需要更多的非规范化和非声明性索引时，尤其如此。

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