理解 Cassandra 背后的哲学
Understanding the philosophy behind Cassandra
我正在尝试熟悉 Apache Cassandra，以完成特定的 PoC 工作。在浏览了网上的各种文章，尝试了各种可用的 libraries/clients 之后，一个特定的问题出现在我的脑海中。
我们想到 Cassandra 的最初原因是因为我们想要一个 'truly' 分布式数据存储。根据我对'distribution'的理解，归根结底是某种'key-value'和某种'consistent hashing'，如果我能够用超级简洁的方式表达自己的话！
因此，像 Cassandra 这样的键值存储非常适合。但是，当我尝试深入研究文章以了解 Cassandra 中的数据建模时，几乎所有文章 explain/exemplify 都使用 CQL。此外，官方声明似乎是 CQL 应该是学习 Cassandra 的 "de jure" 方式。为什么要与 SQL 保持一致？
我不需要关系模型，这就是我来Cassandra的原因。我很欣赏它的基本概念，比如分区 key/clustering 列等，我想了解它是如何在 CQL 的幕后实现的。
请教Cassandra专家，我真的不适合作为Cassandra用户吗？我真的应该忘记键值而只是尝试在我的用例中使用 CQL（如果可能的话）吗？
CQL 不仅仅是 "sugar"，尽管最初创建它是为了鼓励人们从 SQL 世界迁移。 CQL 之前的世界一团糟，许多客户端都使用 Thrift 协议以不同的方式编写——但与 SQL 世界不同的是，Cassandra 每天都在改进，在每个版本中都带来新功能——而且通常每一个改进将需要一个新的 "client version"，能够处理生成的新型结果（例如考虑计数器或集合）或使用新功能的新语法。
我很高兴我有机会在 3 年多的时间里与 Thrift 客户端 (Pelops) 一起投入生产——这帮助我了解了很多 cassandra 世界、数据结构等上——但现在我再也不会回到这样的客户那里了（即使它真的很棒！）。
一开始 Cassandra 完全不同，特别是 was/had
"schema-less" 意味着 CF 的每一行都可以包含不同数量的列，并且没有地方必须放置这些列宣布。这给许多项目带来了灾难，在 "runtime" 处添加新列的可能性导致您不知道在 table.
[=37= 中可以找到什么的情况]
"super-columns" 已弃用的数据结构被 wide-rows
现在数据模型是 stable CQL 语法带来了更多的可读性，您现在可以迁移到您不太熟悉的任何项目，了解应用程序如何与数据库对话的可能性，这要归功于独特的语法 -- 更多 -- 每个新的 Cassandra 版本都紧随其后的是客户端的新版本。
CQL 不是 SQL 的 "subset"，就像许多人写的那样：在某种程度上它是 "superset"，因为它能够处理扩展基本语言的不同数据结构。
我的回答是：以键值方式思考，但仅使用 CQL
HTH,
卡罗
我正在尝试熟悉 Apache Cassandra，以完成特定的 PoC 工作。在浏览了网上的各种文章，尝试了各种可用的 libraries/clients 之后，一个特定的问题出现在我的脑海中。
我们想到 Cassandra 的最初原因是因为我们想要一个 'truly' 分布式数据存储。根据我对'distribution'的理解，归根结底是某种'key-value'和某种'consistent hashing'，如果我能够用超级简洁的方式表达自己的话！
因此，像 Cassandra 这样的键值存储非常适合。但是，当我尝试深入研究文章以了解 Cassandra 中的数据建模时，几乎所有文章 explain/exemplify 都使用 CQL。此外，官方声明似乎是 CQL 应该是学习 Cassandra 的 "de jure" 方式。为什么要与 SQL 保持一致？
我不需要关系模型，这就是我来Cassandra的原因。我很欣赏它的基本概念，比如分区 key/clustering 列等，我想了解它是如何在 CQL 的幕后实现的。
请教Cassandra专家，我真的不适合作为Cassandra用户吗？我真的应该忘记键值而只是尝试在我的用例中使用 CQL（如果可能的话）吗？
CQL 不仅仅是 "sugar"，尽管最初创建它是为了鼓励人们从 SQL 世界迁移。 CQL 之前的世界一团糟，许多客户端都使用 Thrift 协议以不同的方式编写——但与 SQL 世界不同的是，Cassandra 每天都在改进，在每个版本中都带来新功能——而且通常每一个改进将需要一个新的 "client version"，能够处理生成的新型结果（例如考虑计数器或集合）或使用新功能的新语法。
我很高兴我有机会在 3 年多的时间里与 Thrift 客户端 (Pelops) 一起投入生产——这帮助我了解了很多 cassandra 世界、数据结构等上——但现在我再也不会回到这样的客户那里了（即使它真的很棒！）。
一开始 Cassandra 完全不同，特别是 was/had
"schema-less" 意味着 CF 的每一行都可以包含不同数量的列，并且没有地方必须放置这些列宣布。这给许多项目带来了灾难，在 "runtime" 处添加新列的可能性导致您不知道在 table.
[=37= 中可以找到什么的情况]"super-columns" 已弃用的数据结构被 wide-rows
取代
现在数据模型是 stable CQL 语法带来了更多的可读性，您现在可以迁移到您不太熟悉的任何项目，了解应用程序如何与数据库对话的可能性，这要归功于独特的语法 -- 更多 -- 每个新的 Cassandra 版本都紧随其后的是客户端的新版本。
CQL 不是 SQL 的 "subset"，就像许多人写的那样：在某种程度上它是 "superset"，因为它能够处理扩展基本语言的不同数据结构。
我的回答是：以键值方式思考，但仅使用 CQL
HTH, 卡罗