cassandra使用场景判断:何时使用及何时不用-阿里云开发者社区

开发者社区> 中国Cassandra技术社区> 正文

cassandra使用场景判断:何时使用及何时不用

简介: 介绍 我有一个具有以下功能的数据库服务器: 高可用设计。 可以全球分布。 允许应用程序随时随地写入任何节点。 只需向群集添加更多节点即可进行线性扩展。 自动负载及数据均衡。 一种看起来很像SQL的查询语言。

介绍

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

  • 高可用设计。
  • 可以全球分布。
  • 允许应用程序随时随地写入任何节点。
  • 只需向群集添加更多节点即可进行线性扩展。
  • 自动负载及数据均衡。
  • 一种看起来很像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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
中国Cassandra技术社区
使用钉钉扫一扫加入圈子
+ 订阅

Cassandra已有10年+的沉淀,基于Amazon DynamoDB的分布式设计和 Google Bigtable 的数据模型。具备诸多优异特性:采用分布式架构、无中心、支持多活、弹性可扩展、高可用、容错、一致性可调、提供类SQL查询语言CQL等。Cassandra为互联网业务而生,已在全球广大互联网公司有成熟应用,是目前最流行的宽表数据库。阿里云在2019年8月份全球首发云Cassandra服务。

官方博客
相关链接