爬虫场景，可以使用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的混合分析能力。

守护石 「技术创作」
关注领域：大数据技术、分布式架构 ｜ 技术管理