互联网公司常用的基本集中在以下几种,每种只举一个比较常见或者应用比较成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store,同时提供了更加丰富的数据结构和运算的能力,成功用法是替代memcached,通过checkpoint和commit log提供了快速的宕机恢复,同时支持replication提供读可扩展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盘的key-value storage, 模型单一简单,数据量不受限于内存大小,数据落盘高可靠,Google的几位大神出品的精品,LSM模型天然写优化,顺序写盘的方式对于新硬件ssd再适合不过了,不足是仅提供了一个库,需要自己封装server端。
3. Document Store: Mongodb
分布式nosql,具备了区别mysql的最大亮点:可扩展性。mongodb 最新引人的莫过于提供了sql接口,是目前nosql里最像mysql的,只是没有ACID的特性,发展很快,支持了索引等特性,上手容易,对于数据量远超内存限制的场景来说,还需要慎重。
4. Column Table Store: HBase
这个富二代似乎不用赘述了,最大的优势是开源,对于普通的scan和基于行的get等基本查询,性能完全不是问题,只是只提供裸的api,易用性上是短板,可扩展性方面是最强的,其次坐上了Hadoop的快车,社区发展很快,各种基于其上的开源产品不少,来解决诸如join、聚集运算等复杂查询。
不同列族分别存在不同的文件夹里。
与MySQL比较
首先Hbase是依赖于HDFS和zookeeper的。
Zookeeper分担了Hmaster的一部分功能,客户端进行DML语句的时候,都是先跟ZK交互。
RegionServer管理了很多的Region(表),RegionServer里面的WAL(HLog)是预写入日志,功能是防止内存中的数据没有来的及落盘时丢失。在Region里面管理的Store管理的是列族,Store里面有Mem Store(内存),Flush之后,删除内存中的数据,同时写入文件StoreFile Hfile,Hfile 其实是在DataNode里面的。
Hbase的读比写慢。
Hbase命名空间下有一张元数据表meta表和namespace表。meta表里面保存了要 *** 作的表所在的位置等元数据。
(1)首先客户端向zk请求元数据表所在的RegionServer,zk返回给客户端meta表所在的regionServer。
(2)然后客户端再去对应的RegionServer查找meta表,找到真正要 *** 作的表所在的regionServer,同时把meta表的信息缓存下来,加快后续的查询。
(3)然后客户端再向目标表所在的RegionServer发送put请求。先把数据写到Hlog里面,再写到内存MemStore,数据会在内存排序,然后向客户端发送ack,到这里对于客户端来说写数据已经结束了。再等到MemStore的刷写时机后,将数据刷写到Hfile.
注:meta表所在的位置信息保存在zk的meta-region-server节点上,客户端首先就是在这个节点上差询meta表所在的RegionServer。meta表里面的信息就是表与其对应的RegionServer的信息
这个stu表可能不止一条,因为stu表可能数据量大了之后根据RowKey进行了切分,并且可能会在不同的机器上。
不同的列族是在不同的文件夹。
MemStore刷写时机:
全局的MemStore的容量,默认是堆内存的40%。这个容量值会触发flush *** 作,所有的MemStore都要刷写,flush *** 作会阻塞读写 *** 作。
会刷写并阻塞到到MemStore大小降到它的最大容量的95%
WAL日志的刷写时机:
可以设置日志的大小和数量,当达到一定数量,刷写到HDFS
(1)从zk找meta表所在的RegionServer
(2)从上述RegionServer里的meta表里找目标表所在的RegionServer,同时把meta表缓存,加速后面的查询。
(3)向目标表所在的RegionServer发送get请求。可以从block Cache,MemStore还有StoreFile里面查,具体从哪查根据时间戳,查时间戳大的,具体就都查然后merge取最新。
RegionServer里面有block Cache可以缓存磁盘的数据,加速查询。如果block Cache里面有,就将缓存和MemStore的数据merge然后取最新时间戳,没有就是把磁盘读的和MemStore里面的合并。所以hbase大多数读要走磁盘,所以读很慢。
每次刷写会生成新的Hfile,Hfile很小并且数量多的时候会影响查询的速度。所以要进行合并。合并分为minor Compaction和major Compaction
minor Compaction将临近的若干较小的Hfile合并成一个较大的Hfile,不会清理过期和删除的数据,major Compaction会将一个Store里面的所有Hfile合并成一个大的Hfile,并且会清理掉过期和删除的数据。
数据的读写可以不依赖Hmaster,只需要指定zookeeper,但是Hmaster负责region调度的元数据
但是DDL语言是要有Hmaster的
Flush和major Compact
(1)flush在同一个内存中清除过期或删除(删除标记也是一行数据)的数据,但是如果数据不同的版本分布在不同的memStroe,就不能清除。删除的标记在flush之后不会被删,但在后面的major compaction会把删除标记删除掉。
(2)major compaction 会清除过期或删除的数据。
默认情况下,每个Table起初只有一个Region,随着数据的不断写入,Region会自动拆分,两个子Region开始都会在一个Regionserver里面,但是出于负载均衡的考虑,Hmaster有可能会将某个Region传给其他的RegionServer。
Split的时机:
(1)当一个Region中的某个Store下的StoreFile的总大小查过某个值,由参数hbase.hregion.max.filesize设定(默认10g),该Region就会按照RowKey进行拆分。
(2)在新版本中这个值是Min(R^2*"hbase.hregion.memStore.flush.size(128M)","hbase.hregion.max.filesize"),R是当前RegionServer中属于该Table的Region个数。分region是按照RowKey切分的。这会导致数据倾斜,就是因为切分的阈值在变化,导致切分之后的region数据量不均匀,导致热点的问题。所以在建表的时候要做预分区,就是用RowKey规划好多少个region,不让hbase自己的切分逻辑切分。
官方建议只用一个列族,防止不同的列族之间数据不均匀,单一列族数据量增多,导致全局的flush,数据量小的列族也要flush,这样会形成很多小的storeFile。
delete *** 作:
(1)设置RowKey:打的删除标记是deleteFamily,删除多个版本
(2)设置RowKey+Family:打的标记是deleteFamily,删除多个版本
(3)设置RowKey+family+column:有addColumn()和addColumns().addColumn是删除最新的版本或者删除指定时间戳的版本,删除标记是delete标记。addColumns是删除所有的版本或者删除指定时间戳或之前的版本,删除标记是deleteColumn
Delete的 *** 作其实也是put *** 作,put的是删除的标记。
在Hbase中HMaster负责监控HRegionServer的生命周期,均衡RegionServer的负载,如果HMaster挂掉了,那个整个Hbase集群将处于不健康的状态,并且此时的工作状态不会维持太久。所以Hbase支持对HMaster的高可用配置。
在Hbase的conf目录下新建backup-masters文件,vim加入备份Master,比如slave01,slave02.在把文件分发到各个slave里,然后再启动hbase 就能实现HMaster的高可用了。
每一个region维护着StartRow和EndRow,如果加入的数据符合某个region维护的RowKey范围,则该数据交给这个region维护。那么依照这个原则,我们可以将数据所要投放的分区提前大致的规划好,以提高Hbase性能。
(1)手动设定预分区
手动设置RowKey分了5个region
(2)生成16进制序列预分区
(3)按照文件中设置的规则预分区
创建split.txt
然后执行
这里如果文件里面给的分区键不是按照顺序的,hbase会先帮我们把键排序,然后按照键来分区。
(4)使用JavaAPI预分区
admin的创建表的方法有多个重载,可以只传表的描述,也可以加入分区的信息。admin.createTable
规划分区要考虑未来数据量和机器的规模。虽然提前做了分区,但是最后如果分区大于了10G,还是会触发split。假设一台机器有100G磁盘,那么预分区尽量大于10个,这样就能避免预分区之后又触发了大于10G的split。
(1)希望数据能够尽量均匀的分配在多个分区里面(散列性)。
(2)唯一性
(3)长度原则(生产环境70到100位)
常见的设计方案:
(1)生产随机数、hash、散列值
(2)字符串反转
(3)字符串拼接
电信项目:
一次通话的记录:13112341233->18998768771 2018-12-12 12:12:21 568
假设分300个区
分区键怎么设计:
(299个键)
000|
001|
...
298|
RowKey的前面一般会拼上000_,001_,...,298_
这样做的好处是,根据前三位就能知道哪个分区。
(1)我们希望手机号尽量分布在不同的分区,但是相同的手机号数据集中在同一个分区,这样方便查询某个用户的通话信息。000_13112341233
(2)因为每个人通话的需求不同,也希望把同一个人的通话记录也分布在不同的分区里面。000_13112341233_2019-12-12
哈希取余:[(13112341234^201912).hash]%299
假设要查询某用户2019年2月的通话记录,可以用13112341234 201902做startRowkey,13112341234 201903做endRowKey
微博。
1、需求
(1)微博内容的浏览
(2)用户社交:关注用户,取关用户
(3)拉取关注人的微博用户
2、设计表
(1)微博内容表Content
行键:用户id+时间戳
(2)用户关系表
因为正常情况一个用户的粉丝和关注都不多,可以用一行存储关注和粉丝的情况。
行键:用户id
(3)初始化页面的表(显示关注的人的最近三条微博)
阅读数:9381Hbase概述
hbase是一个构建在HDFS上的分布式列存储系统。HBase是Apache Hadoop生态系统中的重要 一员,主要用于海量结构化数据存储。从逻辑上讲,HBase将数据按照表、行和列进行存储。
如图所示,Hbase构建在HDFS之上,hadoop之下。其内部管理的文件全部存储在HDFS中。与HDFS相比两者都具有良好的容错性和扩展性,都可以 扩展到成百上千个节点。但HDFS适合批处理场景,不支持数据随机查找,不适合增量数据处理且不支持数据更新。
Hbase是列存储的非关系数据库。传统数据库MySQL等,数据是按行存储的。其没有索引的查询将消耗大量I/O 并且建立索引和物化视图需要花费大量时间和资源。因此,为了满足面向查询的需求,数据库必须被大量膨胀才能满 足性能要求。
Hbase数据是按列存储-每一列单独存放。列存储的优点是数据即是索引。访问查询涉及的列-大量降低系统I/O 。并且每一列由一个线索来处理,可以实现查询的并发处理。基于Hbase数据类型一致性,可以实现数据库的高效压缩。
HBase数据模型
HBase是基于Google BigTable模型开发的, 典型的key/value系统。一个Row key对应很多Column Family,Column Family中有很多Column。其中,保存了不同时间戳的数据。
如图所示,Rowkey cutting对应列簇info和roles。其中,info中有key-value对hight-9ft,state-CA。更清晰的结构如下图所:
Hbase的所有 *** 作均是基于rowkey的。支持CRUD(Create、Read、Update和Delete)和 Scan *** 作。 包括单行 *** 作Put 、Get、Scan。多行 *** 作包括Scan和MultiPut。但没有内置join *** 作,可使用MapReduce解决。
HBase物理模型
Hbase的Table中的所有行都按照row key的字典序排列。Table 在行的方向上分割为多个Region。、Region按大小分割的,每个表开始只有一个region,随 着数据增多,region不断增大,当增大到一个阀值的时候, region就会等分会两个新的region,之后会有越来越多的 region。
Region是HBase中分布式存储和负载均衡的最小单元。 不同Region分布到不同RegionServer上。
Region虽然是分布式存储的最小单元,但并不是存储 的最小单元。Region由一个或者多个Store组成,每个store保存一个 columns family。每个Strore又由一个memStore和0至多个StoreFile组成。memStore存储在内存中,StoreFile存储在HDFS上。
HBase基本架构
HBase构建在HDFS之上,其组件包括 Client、zookeeper、HDFS、Hmaster以及HRegionServer。Client包含访问HBase的接口,并维护cache来加快对HBase的访问。Zookeeper用来保证任何时候,集群中只有一个master,存贮所有Region的寻址入口以及实时监控Region server的上线和下线信息。并实时通知给Master存储HBase的schema和table元数据。HMaster负责为Region server分配region和Region server的负载均衡。如果发现失效的Region server并重新分配其上的region。同时,管理用户对table的增删改查 *** 作。Region Server 负责维护region,处理对这些region的IO请求并且切分在运行过程中变得过大的region。
HBase 依赖ZooKeeper,默认情况下,HBase 管理ZooKeeper 实例。比如, 启动或者停止ZooKeeper。Master与RegionServers 启动时会向ZooKeeper注册。因此,Zookeeper的引入使得 Master不再是单点故障。
Client每次写数据库之前,都会首先血Hlog日志。记录写 *** 作。如果不做日志记录,一旦发生故障, *** 作将不可恢复。HMaster一旦故障,Zookeeper将重新选择一个新的Master 。无Master过程中,数据读取仍照常进行。但是,无master过程中,region切分、负载均衡等无法进行。RegionServer出现故障的处理原理是定时向Zookeeper汇报心跳,如果一旦时 间内未出现心跳HMaster将该RegionServer上的Region重新分配到其他RegionServer上。失效服务器上“预写”日志由主服务器进行分割并派送给新的 RegionServer 。Zookeeper是一个可靠地服务,一般配置3或5个Zookeeper实例。
寻找RegionServer定位的顺序是ZooKeeper --ROOT-(单Region) -.META. -用户表 。如上图所示。-ROOT- 表包含.META.表所在的region列表,该表只会有一 个Region。 Zookeeper中记录了-ROOT-表的location。 .META. 表包含所有的用户空间region列表,以及 RegionServer的服务器地址。
HBase应用举例
Hbase适合需对数据进行随机读 *** 作或者随机写 *** 作、大数据上高并发 *** 作,比如每秒对PB级数据进行上千次 *** 作以及读写访问均是非常简单的 *** 作。
淘宝指数是Hbase在淘宝的一个典型应用。交易历史纪录查询很适合用Hbase作为底层数据库。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)