了解 Cassandra 背后的哲学

Question

我正在尝试熟悉 Apache Cassandra，以完成特定的 PoC 工作。在浏览了网上的各种文章，尝试了各种可用的库/客户端之后，我脑海中突然出现了一个特定的问题。

我们想到 Cassandra 的最初原因是因为我们想要一个“真正的”分布式数据存储。根据我对“分布”的理解，如果我能够以超级简洁的方式表达自己，它最终归结为某种“键值”和某种“一致性哈希”！

因此，像 Cassandra 这样的键值对存储非常适合。然而，当我尝试深入研究文章以了解 Cassandra 中的数据建模时，几乎所有文章都使用 CQL 进行解释/举例说明。此外，官方声明似乎是 CQL 应该是学习 Cassandra 的“法理”方式。为什么要如此推动与 SQL 保持一致？

我不需要关系模型，这就是我来到 Cassandra 的原因。我很欣赏它的基本概念，比如分区键/集群列等，我想了解它是如何在 CQL 的底层实现的。

询问 Cassandra 的专家，我真的不适合作为 Cassandra 用户吗？我真的应该忘记键值并尝试在我的用例中使用 CQL（如果可能的话）吗？

Answer 1

CQL 不仅仅是一种“糖”，尽管最初创建它是为了鼓励人们从 SQL 世界迁移。 CQL 之前的世界是一团糟，数十个客户端以不同的方式编写，都使用 Thrift 协议——但与 SQL 世界不同的是，Cassandra 每天都在改进，在每个版本中都带来新的特性——而且通常这些改进中的每一个都需要新的“客户端版本”，能够处理生成的新类型的结果（例如考虑计数器或集合）或使用新功能的新语法。

我很高兴我有机会与 Thrift 客户 (Pelops) 一起投入生产超过 3 年——这帮助我了解了很多 cassandra 世界、数据结构等等—— - 但现在我再也不会回到这样的客户那里了（尽管它真的很棒！）。

一开始Cassandra完全不同，特别是曾经/曾经

• “无模式”意味着 CF 的每一行可以包含不同数量的列，并且没有必须声明这些列的地方。这给许多项目带来了灾难，在“运行时”添加新列的可能性导致您不知道可以在表中找到什么。

• "super-columns" 已弃用的数据结构被宽行替换

既然数据模型是稳定的，CQL 语法带来了更多的可读性，您现在可以迁移到任何您不熟悉的项目，通过独特的语法了解应用程序如何与数据库对话的可能性 - 更多 - - 每个新的 Cassandra 版本都会紧跟新版本的客户端。

CQL 不是 SQL 的“子集”，就像许多人所写的那样：在某种程度上它是“超集”，因为它能够处理扩展基础语言的不同数据结构。

我的回答是：以键值方式思考，但只使用 CQL

HTH, 卡罗