第一章 Hbase专题之产生背景&分布式数据库设计要点

1、Hbase产生背景

1.1、hadoop特点

(1)存储:对于任意格式的庞大数据集,hadoop可以做到安全存储

(2)单条记录:无法在庞大数据集中做针对单条记录随机的低延迟的增删改查

1.2、hive特点

(1)存储:对于存储在HDFS上的结构化数据抽象成为一张二维表格,使用Hive进行各种Insert/select操作

(2)单条记录:Hive还是天生不支持对于单 条记录的增删改查,也不是设计用来做单条记录的增删改查的。

1.3、传统关系型数据库

(1)海量数据量存储成为瓶颈,单台机器无法负载大量数据

(2)单台机器IO读写请求成为海量数据存储时候高并发大规模请求的瓶颈

(3)随着数据规模越来越大,大量业务场景开始考虑数据存储横向水平扩展,使得存储服务可以增加/删除, 而目前的关系型数据库更专注于一台机器

2、分布式数据库设计方案

5.1、业务场景

(1)京东,有史以来所有的交易快照有上千亿数据,请问,如何给用户理解返回点击查询某次交易详情的快照 信息呢?

(2)腾讯QQ和微信聊天记录,当*系统需要调用聊天记录来作为证据时候,需要从上十亿用户经年累月的聊 天记录快速定位某天的聊天记录内容呢?

(3)谷歌nutch爬取数以万亿级的网页分析数据又该如何做针对记录级别的随机读写呢?

2.2、设计目标
  • 目标概述:要一个不管数据量多大,都能做到针对单条记录的低延时随机读写组件。

(1)分布式

(2)低延时

(3)支持记录级别的CURD

(4)确保数据一致性

3.3、设计难点

(1)怎样快速判断一个元素在不在一个数据集中?

  • CASE:集群有100个节点,文件100T,每个节点存储1T文件,如何快读定位某条记录在某个节点上?

  • 解决方案:布隆过滤器,快速判断一个元素是否存在一个庞大的集合内

(2)是否能找到一种合适的数据结构和搜索算法能快速从一个数据集中找出一个元素?

  • CASE:集群有100个节点,文件100T,每个节点存储1T文件,如果已知某条数据存储到某个节点,如何在这个节点中的文件快速查找出这条记录?

  • 解决方案:顺序数据集中的二分查找

(3)如何设计分布式系统?

  • CASE:

  • 解决方案:网络编程模型NIO RPC Netty:

(5)是否可以提前过滤不参与查询的数据,提高查询效率?

  • CASE:集群有100个节点,文件100T,每个节点存储1T文件,如果已知某个字段数据存储到某个节点,如何在这个节点中的文件快速查找出这条记录?

  • 解决方案:列裁剪,列式存储,谓词下推

4.4、设计要点

(1)提高查询效率

①内存 + 磁盘

热数据(经常查询数据)放在内存中,冷数据放在磁盘中

②内存数据良好的数据结构

​ 内存中采用高性能数据结构,提高数据CURD效率。

③磁盘数据 + 布隆索引

​ 磁盘文件数据加上索引提高查询效率

  • 没有索引:顺序从前到后扫描
  • 建立索引:通过索引将数据分段,通过定位数据区间查询数据提高查询性能

④范围分区 + 排序

在内存中的数组数据结构进行数据排序,之后将所有溢写的小文件最后进行归并排序

  • 注意事项:海量数据查找
    • ①暴力扫描
    • 先排序、然后通过范围分区+分段扫描

跳表Topo结构

​ 本质上就是将二分查询物化成一张元数据表,根据元数据表确定记录在那个节点,将原本扫描所有节点数据变为扫描一个节点。

第一章 Hbase专题之产生背景&分布式数据库设计要点

⑥读缓存 + 写缓存

  • 读缓存:客户端短时间内缓存上一次的查询数据/或者热数据,下次查询同样的数据可直接读取缓存文件,而不用在服务端查询。
  • 写缓存:数据输出有序,并建立索引

第一章 Hbase专题之产生背景&分布式数据库设计要点

(2)确保数据安全

①内存 + 磁盘

②WAL机制

在任何数据增删改之前,都会记录操作日志,之后才把数据更新到内存

上一篇:开发一个工作录小程序----明日工作


下一篇:小程序里input宽度与文字显示的问题