Cassandra 数据模型设计,根据你的查询来制定设计——反范式设计本质:空间换时间

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介:

转自:http://www.infoq.com/cn/articles/best-practice-of-cassandra-data-model-design

不要把Cassandra model想象成关系型数据库table

取而代之,应该把它想象成事一个有序的map结构。

对于一个新手来说,下面关系型数据库术语常常被对应到Cassandra模型

 

这种对比可以帮助我们从关系型数据库转换到非关系型数据库。但是当设计Cassandra column famiy的时候请不要这样去类比。取而代之,考虑它是一个map中嵌入另一个map:外部map的key为row key,内部map的key为column key,两个map的key都是有序的。如下:

SortedMap<RowKey, SortedMap<ColumnKey, ColumnValue>>

why?

将column family想象成嵌套的并排序的map比关系型数据库table描述的更为准确,它将帮助你正确的进行Cassandra模型设计。

How?

  • Map可以进行高效查询,同时排序的特性可以进行高效column扫描。在Cassandra中,我们可以使用row key和column key做高效查找和范围扫描
  • Column key的数量是很庞大的(译者注:目前译者所使用的Cassandra1.2.5版本,每个row支持最多20亿个columns)。换句话说你,你可以拥有一个wide rows。
  • Column key自身可以存储值,即你可以拥有一个没有值的column。

如果集群使用Order Preserving Partitioner (OOP)策略进行数据存储,就可以对row key进行范围查询。但是OOP大多数情况都不推荐使用(译者注:将rowkey按照顺序存储到节点上,如果分区不均匀,将导致数据读写不均衡),所以你可以认为外部的map是不排序的,如下:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

上面提到的”Super Column”,认为它们是一组column,这样的话,两级嵌套map就会像下面展示的一样变为三级嵌套map:

Map<RowKey, SortedMap<SuperColumnKey,
           SortedMap<ColumnKey, ColumnValue>>>

注意:

  • 你需要传递timestamp给每个column value,因为Cassandra使用它做内部的冲突处理机制。但在建模过程中你可以忽略它(译者注:在操作column的时候timestamp信息 会自动添加到column)。同时,不要考虑在你的程序中使用column的timestamp,因为它不是为你设计的,与Hbase不同,它们不会生成 新的version数据(译者注:在Hbase中相同rowkey和column key的数据会保存多个version,而Cassandra会将相同数据覆盖,timestamp只保存最后一次更新的时间)。
  • 因为Super Column的性能问题和缺乏二级索引支持问题,Cassandra社区对它的使用曾有过强烈争议。所以,推荐使用Composite Columns代替Super Column实现功能。(译者注:使用Super Column,如果你要获取其中一个columnvalue,则要扫描整个Super Column,这会导致查询性能很糟糕)

围绕着查询模式进行Column Family建模

建模尽量从实体和它们的关系开始

  • 与关系型数据库不同,在Cassandra中通过创建二级索引或者编写复杂SQL(使用joins, order by, group by)来新建或修改查询不是件容易的事情。因为Cassandra具有很高的分布式特性,所以要先考虑查询模式,然后再设计column family。
  • 牢记前面提到的嵌入排序map数据结构,在考虑如何组织你的数据到map,以满足快速查询/排序/分组/过滤/聚合的要求。

在大部分情况下,实体和它们的关系是很重要的(特殊用例除外,如日志存储或者其它时间序列数据)。如果我给你一个查询模式,用于为一个电子商务网站 创建Cassandra模型,但不告诉你任何实体和它们的关系。你会有意或者无意的从查询模式或者从你之前领域对象的理解找出实体和它们之间的关系(因为 我们是通过实体和关系来描述真实世界)。在设计数据模型时最好从实体和关系开始,然后使用反范式化和冗余的方式继续围绕查询模式建模。如果这听起来有些让 人困惑,通过后面的详细例子就可以理解。

注意:在建模的时候考虑以下几点会很有帮助。区分频次大的查询和频次小的查询,有些查询可能只被查询几千次,其它可能被查询数十亿次;还要考虑哪些查询对数据延迟是敏感的。确保你的模型优先满足查询频次大的查询和重要查询。














本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6279079.html,如需转载请自行联系原作者


相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
1月前
|
存储 传感器 算法
【软件设计师备考 专题 】设计物理数据:数据特性分析和逻辑数据组织
【软件设计师备考 专题 】设计物理数据:数据特性分析和逻辑数据组织
53 1
|
存储 SQL 大数据
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)
|
10月前
|
分布式计算 关系型数据库 BI
KYLIN 建模设计学习总结(概念、空间优化、查询性能优化)
KYLIN 建模设计学习总结(概念、空间优化、查询性能优化)
93 0
|
算法 Python
多变的夏普率(一)(2022-03-18更新)
多变的夏普率(一)(2022-03-18更新)
174 0
多变的夏普率(一)(2022-03-18更新)
|
存储 前端开发
谈谈数据标准和数据模型
标准定义了一个参考框架,强化交互各方之间的信任。例如,当您在加油站加满汽车油箱时,“升”汽油的标准定义将确保您获得的汽油量是您认为的。反过来,“人民币”的标准定义向加油站所有者保证,您正在向他支付您购买的汽油的适当价值。
谈谈数据标准和数据模型
|
数据采集 供应链 监控
谈谈哪种数据管理模式好
很多组织对更好的数据质量有很高的标准化需求。大多数源自企业内部的活动,如流程优化或源自法律法规的需求。
谈谈哪种数据管理模式好
|
数据库 索引 大数据
这才是真正的表扩展方案
事情变得有意思了,上一篇花1小时撰写的“一分钟”文章,又引起了广泛的讨论,说明相关的技术大家感兴趣,挺好。第一次一篇技术文章的评论量过100,才知道原来“评论精选”还有100上限,甚为欣慰(虽然是以一种自己不愿看到的方式)。
594 0
【自然框架】之“元数据”的威力
定义      元数据最本质、最抽象的定义为:data about data (关于数据的数据)。它是一种广泛存在的现象,在许多领域有其具体的定义和应用。       我的理解就是对数据进行说明、描述。
824 0
|
算法
自然框架,拆分后的项目关系
  拆分了一下自然框架,似乎又绕回去了。以前是多个项目分开放的,有人说太分散了,还得一个个下载,麻烦。于是就做了一个解决方案,把项目都放在了一起。     现在呢,QuickPager分页控件比较完善了,有人只想看分页控件的代码,其他的不想看,东西太多了乱。
825 0