正确建模
开发人员在构建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的一些好场景是： - 交易日志：购买，测试分数，观看的电影等。
- 存储时序数据（需要您自行聚合）。
- 跟踪几乎任何事情，包括订单状态，包裹等。
- 存储健康追踪数据。
- 气象服务历史。
- 物联网状态和事件历史。
- 汽车的物联网数据。
- 电子邮件