介绍

我有一个具有以下功能的数据库服务器：

• 高可用设计。
• 可以全球分布。
• 允许应用程序随时随地写入任何节点。
• 只需向群集添加更多节点即可进行线性扩展。
• 自动负载及数据均衡。
• 一种看起来很像SQL的查询语言。
  听上去是不是很酷，cassandra确实涵盖上述功能列表，那是不是我们可以采用cassandra满足我们所有的数据库需求？很不幸，我在很多cassandra商业公司上都听到上述推销，确实也有很多人相信，很多以前用oracle,mysql这样的专有数据库用户也希望能节约大量的license费用，他们默认cassandra也具有oracle,mysql相同的关系型数据库核心能力，但cassandra实际上还不具备。

在这篇博文中，我将讨论一些需要避免的陷阱，为Cassandra提供一些好的用例，并提供一些数据建模建议。

Cassandra用户容易用错的地方

由于以下一个或多个原因，Cassandra项目往往会失败：

• 没有正确建模
• 使用了错误的Cassandra功能。
• 使用场景对Cassandra来说是完全错误的。

正确建模

开发人员在构建Cassandra数据库时犯的另一个主要错误是分区键的选择不佳。
cassandra是分布式的。这意味着您需要有一种方法来跨节点分布数据。Cassandra通过散列每个表的主键（称为分区键）的一部分并将散列值token分配给集群中的特定节点来完成此操作。选择分区键时，请务必考虑以下规则：

• 应该有足够的分区键值，以便在群集中的所有节点之间均匀地分布数据。
• 最好单个分区涵盖一次读所想拿到的数据
• 不要让分区太大。Cassandra可以处理大于100MB的大分区，但效率不高。此外，如果您划分的分区很大，则说明您的数据分发不太可能是均匀的。
• 理想情况下，所有分区的大小大致相同。
  典型的真实世界分区键是用户ID，设备ID，帐号等。为了管理分区大小，通常将诸如年，月或年的时间修饰符添加到分区键。

这点在所有分布式数据库都是一样的，不再赘述。

错误的功能

Cassandra目前有一堆实验级别的功能，可能这些功能不应该存在，容易对用户造成混淆，容易让人误以为能做到关系数据库做到的任何事情：

• 二级索引：它们有自己的用途，不能滥用，不能替代表的访问
• 计数器(counter)：它们能正常工作，但它们开销非常大，不应经常使用。
• 轻量级事务：并非事务，也完全不轻量级。
• 批处理：一次向服务器发送一堆操作通常很好，节省了网络时间，对吧？那么在Cassandra时表现就不那么好了
• 物化视图：它看起来很有意义。但目前仍是实验级别的，实现还不完备，如不能保证跟base表保持sync，如果有不一致，只能先删，再重建。
• CQL：看起来像SQL让人们误以为它是SQL。
  使用上述任何功能，您希望它们在传统数据库中工作的方式肯定会导致严重的性能问题，并且在某些情况下会导致数据库损坏。

Cassandra的错误使用案例

如果您有一个数据库，您依赖以下任何一项内容 - Cassandra对您的需求都是不合适的，请不要使用Cassandra。

• 表需要有多个访问路径。示例：许多二级索引。
• 应用程序依赖于底层数据库自增主键功能。MySQL自增主键或Oracle序列。
• cassandra不支持ACID，没有事务，CQL没有开始/提交事务语法，如果你确实需要事物，尝试其他数据库。
• 聚合：Cassandra不支持聚合，如果你需要做很多聚合，尝试其他数据库。
• Joins：Cassandra不支持Join，nosql数据库都是反数据库范式设计的。
• 锁：Cassandra不支持锁定。这是跟底层实现有关，各node都是对等的，可并发写，不是强主模式。
• 并发更新：大量的并发更新会带来数据的正确性问题，上层应用往往需要先读后更新。
  如果您需要上述的任何一个功能，cassandra支持的都不是很好，请考虑使用可能更符合您需求的其他数据库技术。

什么时候应该考虑使用Cassandra

每个数据库服务器都是为满足特定的设计目标而构建，这些设计目标定义了数据库适合和不适合的场景。
Cassandra的设计目标如下：

• 分布式：在多个服务器节点上运行。
• 线性扩展：通过添加节点实现水平扩容
• 全球分布：群集可以在地理上分布。
• 写优于读：写入比读取快一个数量级。
• *对等架构：没有主/从。
• 支持分区容忍度和可用性而不是一致性：最终一致（参见CAP定理：https：//en.wikipedia.org/wiki/CAP_theorem。）
• 通过主键支持快速目标读取：关注主键读取，其他路径次优。
• 支持具有生命周期的数据：Cassandra数据库中的所有数据都具有已定义的生命周期，生命周期到期后自动删除数据。
  功能列表中没有关于ACID，关系型库中常见聚合等功能。此时您可能会想，“那它有什么用？”ACID，Join和聚合对于所有数据库至关重要。没有ACID意味着没有原子，没有原子操作，你如何确保任何事情都正确发生，如何保证一致。Cassandra的的确确确实不能保证，所以如果您考虑选型某数据库来跟踪银行的账户余额，您可能应该考虑其他选择。

理想的cassandra使用场景

事实证明，Cassandra对某些应用程序非常有用。
理想的Cassandra应用程序具有以下特征：

• 写入大幅度超出读。
• 数据很少更新，并且在进行更新时它们是幂等的。
• 通过主键查询，非二级索引。
• 可以通过partitionKey均匀分区。
• 不需要Join或聚合。
  我最推荐使用Cassandra的一些好场景是：
• 交易日志：购买，测试分数，观看的电影等。
• 存储时序数据（需要您自行聚合）。
• 跟踪几乎任何事情，包括订单状态，包裹等。
• 存储健康追踪数据。
• 气象服务历史。
• 物联网状态和事件历史。
• 汽车的物联网数据。
• 电子邮件

结论

通常，管理人员和开发人员只关注某项技术的功能集。在处理分布式数据库时，识别数据和工作负载的分布方式也非常重要。如果不了解设计标准和具体的实现，任何使用像Cassandra这样的分布式数据库的尝试都将失败。通过本文了解cassandra使用场景是非常有必要的。

钉钉群交流
为了营造一个开放的 Cassandra 技术交流，我们建立了微信群和钉钉群，为广大用户提供专业的技术分享及问答，定期在国内开展线下技术沙龙，专家技术直播，欢迎大家加入。

钉钉群入群链接：https://c.tb.cn/F3.ZRTY0o