使用 CQL 脚本的 Cassandra 模式管理答案

【问题标题】：Cassandra Schema Management with CQL scripts使用 CQL 脚本的 Cassandra 模式管理
【发布时间】：2014-07-01 10:09:14
【问题描述】：

致 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 代码开发、部署和维护的选择和最佳实践有所了解。一如既往地感谢。

【问题讨论】：

我发布这个问题已经几个月了，但没有多少人发表评论......开始怀疑我对 CQL 开发的期望是否太高。
我认为这是每个人都有的问题，但没有简单的解决方案，因为 Cassandra 中的迁移从来没有关系数据库那么简单。

标签： database cassandra build-process cql datastax

【解决方案1】：

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

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

【讨论】：