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

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介:

转自: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数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
6月前
|
存储 传感器 算法
【软件设计师备考 专题 】设计物理数据:数据特性分析和逻辑数据组织
【软件设计师备考 专题 】设计物理数据:数据特性分析和逻辑数据组织
152 1
|
存储 SQL 大数据
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)
|
4月前
|
存储 数据格式 运维
开发与运维C++问题之更改数据模型为通用数据结构如何解决
开发与运维C++问题之更改数据模型为通用数据结构如何解决
29 1
|
4月前
|
Java Spring
通用研发提效问题之配置的若干场景下若干方案的变化该如何解决
通用研发提效问题之配置的若干场景下若干方案的变化该如何解决
|
4月前
|
数据库
业务系统架构实践问题之当一个模型既有独立性又有与其他模型的关联时,判断它是否为聚合根问题如何解决
业务系统架构实践问题之当一个模型既有独立性又有与其他模型的关联时,判断它是否为聚合根问题如何解决
|
消息中间件 缓存 NoSQL
程序员快来学习缓存层场景实战数据收集—技术选型思路及整体方案
根据以上业务场景,项目组提炼出了6点业务需求,并针对业务需求梳理了技术选型相关思路。 1)原始数据海量:对于这一点,初步考虑使用HBase进行持久化。 2)对于埋点记录的请求响应要快:埋点记录服务会把原始埋点记录存放在一个缓存层,以此保证响应快速。关于这一点有多个缓存方案,稍后展开讨论。 3)可通过后台查询原始数据:如果直接使用HBase作为查询引擎,查询速度太慢,所以还需要使用Elasticsearch来保存查询页面上作为查询条件的字段和活动ID。
|
SQL 存储 缓存
我们常说的数据库优化,可以从哪些维度入手?
我们常说的数据库优化,可以从哪些维度入手?
132 0
|
分布式计算 关系型数据库 BI
KYLIN 建模设计学习总结(概念、空间优化、查询性能优化)
KYLIN 建模设计学习总结(概念、空间优化、查询性能优化)
148 0
|
存储 前端开发
谈谈数据标准和数据模型
标准定义了一个参考框架,强化交互各方之间的信任。例如,当您在加油站加满汽车油箱时,“升”汽油的标准定义将确保您获得的汽油量是您认为的。反过来,“人民币”的标准定义向加油站所有者保证,您正在向他支付您购买的汽油的适当价值。
谈谈数据标准和数据模型
|
大数据 BI
一篇文章搞懂数据仓库:维度表(设计原则、设计方法)
一篇文章搞懂数据仓库:维度表(设计原则、设计方法)
一篇文章搞懂数据仓库:维度表(设计原则、设计方法)
下一篇
无影云桌面