本文主要是介绍爬虫场景,可以使用TiDB替代HBase吗?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
爬虫场景是典型的写多读少,咱们先看看HBase和TiDB的架构,再做进一步判断。
一、 HBase主要分为Master Server,region Server的主服务,以及需要HDFS,ZooKeeper的支撑服务。
(1)Master Server用于协调Region Server,而Region Server对外提供自身大量Region单元和wals的读写访问,以及对Region的维护。一个region单元又对memstore,storefile的内存和磁盘中数据实现读写和数据结构维护。
(2)Region Server作为Hadoop HDFS的客户端,将写入自身的WAL HLog文件和HStore的 HFile文件保存在HDFS仓库中,并随时应用于查找。
HBase的主要优势就在两层:
第一层优势:Region可以不断被拆分,由master将其分配到不同Region Server上,形成均匀的数据分布,Region本质就是对HBase table的一个列簇进行分裂,可以类比成传统数据库的分表,那么再大的列族也会按照行键进行Region分裂,并分布在不同的服务节点上,这样就可以通过集群提升整体数据的读写性能。
第二层优势更为关键,Region实际上是个LSM-Tree的超大数据结构,也就是从客户端写进一个Region Server数据,会不经历任何特殊转换过程,也不经历任何分布式联合过程,数据直接进入Region的LSM-Tree,这点就与tidb大为不同,TiDB从客户端到最终写入要经历复杂的SQL语义转换和多节点协作。
HBase批次的写入都会现在LSM-Tree的Memestore中缓冲,大概128m就进行一次Flush,那么每次读取的过程又可以先从Memestore中查找,没有的情况再从Blockcache中查找,仍然没有才会在hfile中做类b树的查找和扫描。
这就极为突出写入过程中的巨大性能优势,而且对最近写入数据和经常访问数据,提供了更快的查找策略。这些特点都非常适合爬虫,爬虫首先就是并行,更迅速地抓取和写入,然后再配合spark做实时清洗,形成统计表或图处理。列族又能根据不同网站特征,增加无数种不同特征的字段类型,并形成超大稀疏表。
二、我们再反观TiDB,尽管集群中的tikv部分选择了Rockesdb,也是LSM-Tree结构,但这只是TiDB很小的一部分,TiDB的关键目的不是完成海量数据的写入,实时流处理和联机分析,它的关键目的在于分布式的环境下实现在线事务处理,为了达到这个目的它有前置集群TiDB来解决SQL的解析,优化和分布式事务,它有调度集群pd,实现对不同tikv节点的协调调度,它有tikv集群通过raft算法实现分布式数据访问的一致性操作,因此TiDB的主战场是联机事务场景,而它的次级战场才是因为其具有分布式kv特征的联机分析场景。
理解其架构特点,我想你就一定会明白,爬虫的业务场景更符合HBase的架构特长,大量采集数据的高性能写入和实时清洗以及借助HDFS的海量存储,并实现离线分析OLAP;
而对于TiDB强在对上层实时业务的SQL读写访问支撑,数据更新在分布式场景下的强一致性和事务处理能力,因此还是应该把它的重心放在分布式的OLTP应用上,同时可以兼备轻型OLAP的混合分析能力。
守护石 「技术创作」
关注领域:大数据技术、分布式架构 | 技术管理
这篇关于爬虫场景,可以使用TiDB替代HBase吗?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!