Hbase之表设计原则

1、列簇的设计

  • 列簇尽量少,最好不超过3个。因为每个列簇是存在一个独立的HFile里的,flush和compaction操作都是针对一个Region进行的,当一个列簇的数据很多需要flush的时候,其它列簇即使数据很少也需要flush,这样就产生的大量不必要的io操作。
  • 在多列簇的情况下,注意各列簇数据的数量级要一致。如果两个列簇的数量级相差太大,会使数量级少的列簇的数据扫描效率低下。
  • 将经常查询和不经常查询的数据放到不同的列簇。
  • 因为列簇和列的名字会存在HBase的每个Cell中,所以他们的名字应该尽可能的短。比如,用f:q代替mycolumnfamily:mycolumnqualifier

2、rowkey的设计

  • 避免使用递增的数字或时间做为rowkey。
  • 如果rowkey是整型,用二进制的方式比用string来存储更节约空间
  • 合理的控制rowkey的长度,尽可能短,因为rowkey的数据也会存在每个Cell中。
  • 如果需要将表预分裂为多个region是,最好自定义分裂的规则。
时间: 2024-11-01 06:24:51

Hbase之表设计原则的相关文章

Hbase中rowkey设计原则

Hbase中rowkey设计原则 1.热点问题 在某一时间段,有大量的数据同时对一个region进行操作 2.原因 对rowkey的设计不合理 对rowkey的划分不合理 3.解决方式 rowkey是hbase的读写唯一标识 最大长度是64KB. 4.核心原则 设计必须按照业务需求进行设计 5.长度原则 经验:10~100字节可以 官方:16字节,因为操作系统时8字节进行存储 6.散列原则 划分region是按照rowkey的头部进行划分. 有几种方式: )组合字段 id+timestamp )

mysql web数据库的设计归范-2表设计原则

[职责分离原则] 职责分离原则是指在设计的时候应当考虑到数据的产生,聚合使用等原则,每个系统干自己能干的事情,每个系统只干自己的事情.一个数据表应该放在哪个系统中,通常取决于几点: 1. 谁产生这个信息:通常情况下谁产生了这个数据应当对此数据负责:也就是考虑该数据的创建,发展,销毁等全生命周期的定义,并将这个定义维护起来提供给消费者作为消费原则: 2. 谁最经常使用这个信息:如果某个系统最经常使用这个数据,最经常去修改某个数据,也应该由该系统来负责保存维护该数据: 3. 遵守高内聚,低耦合的考虑

数据库表设计原则

(1)不应针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计:不同组件间所对应的数据库 表之间的关联应尽可能减少,如果不同组件间的表需要外键关联也尽量不要创建外键关联,而只是记录关联表的一个主键,确保组件对应的表之间的独立性,为系统 或表结构的重构提供可能性. (2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计,首先分析系统业务,根据职责定义对象.对象要符合封装的特性,确保与职责相关的数据项被定 义在一个对象之内,这些数据项能够完

mysql数据库关系表设计原则

https://blog.csdn.net/qq_36432666/article/details/78934073 https://kb.cnblogs.com/page/138526/ http://blog.sina.com.cn/s/blog_a29f7cb50101jr5d.html https://www.cnblogs.com/mjbrian/p/6841226.html https://blog.csdn.net/persistencequxi/article/details/7

Habse中Rowkey的设计原则——通俗易懂篇

Hbase的Rowkey设计原则 一. Hbase介绍 HBase -> Hadoop Database,HBase是Apache的Hadoop项目的子项目.HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.另一个不同的是HBase基于列的而不是基于行的模式,主要用来存储非结构化和半结构化的松散数据(列存NoSQL数据库) 二. 设计原则 2.1 Rowkey长度原则 Rowkey是一个二进制码流,Rowkey的长度被很多开发者建议设计在10-100个字节,不过建议是越短

hbase表设计优化原则 ***** 生产环境中使用小结

2019/2/28 星期四 hbase表设计优化原则 https://www.cnblogs.com/qingyunzong/p/8696962.html表设计1.列簇设计 追求的原则是:在合理范围内能尽量少的减少列簇就尽量减少列簇. 最优设计是:将所有相关性很强的 key-value 都放在同一个列簇下,这样既能做到查询效率 最高,也能保持尽可能少的访问不同的磁盘文件. 以用户信息为例,可以将必须的基本信息存放在一个列族,而一些附加的额外信息可以放在 另一列族.2.RowKey 设计 HBas

HBase概念学习(八)开发一个类twitter系统之表设计

这边文章先将可能的需求分析一下,设计出HBase表,下一步再开始编写客户端代码. TwiBase系统 1.背景 为了加深HBase基本概念的学习,参考HBase实战这本书实际动手做了这个例子. 2.需求 这是一个用户推特系统,用户登陆到系统,需要维护用户的基本信息,然后用户可以发帖和其他用户进行互动.用户之间可以相互关注,用户可以浏览关注用户的推文等等. 这是一个比较简单的推特系统,不考虑用户之间的私信,用户评论推特等功能. 3.概要设计 3.1表设计 首先需要设计三个表:用户表,推特表以及用户

表设计的原则与方法分析:追求表价值的最大化

表设计的原则与方法分析:追求表价值的最大化 在对象关系映射的应用系统设计中,对象就是表.对象关系即表关系,脱离对象设计表是错误的.对象的存在或价值在于它与其他对象的关系(设计研究的就是怎样处理对象以及对象之间的关系),不与其他对象产生关系的对象,或者说不与其他表有关系的表是没有价值的,不应创建. 当需求确定開始对系统进行设计时,首先进行对象分析.每个对象应具有唯一性,即对象的属性和方法唯一,能够明白的代表现实世界中的一种对象,因此与该对象相应的表的字段也具备唯一性.即在其它表中不应有反复字段.

数据库表设计三大范式原则

a  所有字段值都是不可分解的原子值 b  也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中 c   数据表中的每一列数据都和主键直接相关,而不能间接相关 1.第一范式(确保每列保持原子性) 第一范式是最基本的范式.如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式. 第一范式的合理遵循需要根据系统的实际需求来定.比如某些数据库系统中需要用到"地址"这个属性,本来直接将"地址"属性设计成一个数据库