数据迁移——技术选型
Posted shuaisunny
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据迁移——技术选型相关的知识,希望对你有一定的参考价值。
日常我们在开发中,随着业务需求的变更,重构系统是很常见的事情。重构系统常见的一个场景是变更底层数据模型与存储结构。这种情况下就要对数据进行迁移,从而使业务能正常支行。
背景如下:老系统中使用了mongo数据库,由于目前缺乏运维人员,故需要将数据迁移到其他库中。
本文主要介绍技术数据迁移前技术选型。
对于NoSQL数据库,首先想到的MongoDB、ElasticSearch、Redis、HBase、ClickHouse,对于这五种数据库,到底该选择哪个?想必这是开发者在技术选型上遇到的难题。下面就先介绍下这五种热门数据库的优缺点及应用场景,更深刻的理解这几种数据库的特点,然后作出正确的数据库选择。
MongoDB
MongoDB最大特点是表结构灵活可变,字段类型可随时修改。MongDB中的每一行数据只是简单的被转化为JSON格式后存储。缺点当然是在多表查询、复杂事务等高级操作上表现欠佳。
Redis
对于redis,在研发项目中使用的就太多了,一般搭建的是Cluster集群模式,实现了分布式存储,在保证高可用中引入了主从模式。在使用过程中需要关注redis的热key问题(针对于这一点,目前我开发了热key探测,适量增加应用本身些许内存就彻底解决该问题,后续有详细的博文进行介绍)及大key问题。
ElasticSearch
ElasticSearch是一个近实时的分布式搜索分析引擎,它的底层存储完全构建在lucene之上, 其特点就是搜索,因此ES的方方页面也都是围绕搜索设计的。ES除了搜索外,还会自动的对所有字段建议索引,以实现高性能的复杂聚合查询,因此只要写入ES的数据,无论再复杂的聚合查询也可以得到不错的性能。
ES的写入,会经历write -> refresh -> flush -> merge等过程,只有refresh到文件缓存后,才能搜索可见,因此我们说ES是近实时搜索而非实时的原因。ES为了减少磁盘IO保证读写性能,每隔5s才会把lucene里的Segement进行持久化,为了保证数据不丢失,也借鉴了数据库的处理方式,增加了TransLog模块,在每一个shard中,写入流程分为两个部分,先写入luncene,再写入transLog(这里与mysql中的WAL是相反的,留个思考题,Why?)
Es在变更主要时,采用『先查原记录-生成新记录-删除原记录-写入新记录』的方式,如果有冲突,通过版本号解决 ;对于ES的读,这里就不详细介绍。
总得来说,Elasticsearch的并发处理能力立足于内存Cache,比较依赖内存的,并且对内存的消耗较大,属于高硬件资源消耗,在性能优化方面,除了机器本身的性能,JVM调调优外,还可以结合业务采取数据预热、冷热分离、读写分离等等。
HBase
HBase是一种构建在HDFS之上的分布式、面向列的存储系统,每一行数据都有rowKey,在HBase系统架构中,有client、hMaster、hRegionServer、HRegion、Store、HLog、MemStore、StoreFile、hFile等概念,此处不再详述。本质上讲,HBase相当于把逻辑的一张大表按照列族分拆成若干小表分别进行存储,对于行簇当达到一定数量后也会再被拆分,这种存储特性带来了海量数据规模的支持和极强的扩展能力,缺点就是对于复杂的查询(如查询条件涉及多列或无法获取查询的rowKey)时查询效率是相当低下的。另外,hBase在数据写入时默认wal,然后是memstore即数据持久化,与es相比,可以保证写后立即查询到数据。
优点:
(1) 继承了hadoop项目的优点,适合对海量数据的支持
(2) 极强的横向扩展能力
(3) 使用廉价的PC机就能够搭建起海量数据处理的大数据集群
缺点:
对数据的读取带来了局限,只有同一列族的数据才能够放在一起,而且所有的查询都必须依赖于key,这就使得很多复杂的查询难以实现
应用场景:
由于列式存储的能力带来了海量数据的容纳能力,因此非常适合数据量极大、查询条件简单、列与列之间联系不大的场景
ClickHouse
ClickHouse是战斗民族Yandex开发的完全列式存储计算的分析型数据库。与ES的写入相比,CK所有的数据写入时直接落盘,同时也就省略了传统的写redo日志阶段。在极高写入吞吐要求的场景下,es和CK都需要为了提升吞吐而放弃部分写入实时可见性。只不过CK主推的做法是把数据延迟批量写入交给客户端来实现,在多副本同步上,CK依赖于zk做异步的磁盘文件同步(data shipping),而es是实时同步(即写入请求必须写完多个副本才会返回,因此副本的数量对es的写入性能也是有影响的)。
上面提到CK是分析型数据库,这种场景,数据一般是不变的,因此CK对update、delete的支持较弱(通过alter方式异步实现)。
HBase | ClickHouse | |
数据存储 | Zookeeper保存元数据,将数据写入HDFS中(非结构化的数据) | Zookeeper保存元数据,数据存储在本地,且会极致压缩 |
查询 | 使用Phoenix协助处理器 | 高效的查询能力 |
数据读写 | 支持随机读写,删除。更新操作是插入一条新的timestamp的数据 | 支持读写,但不能删除与更新 |
数据迁移方案:
在mongo数据迁移的过程中,上述哪一种存储方案都存在缺点,即然一种存储方案都不能有效解决,最好的方式就是组合,吸取每种存储的做点。目前存储在mongo的数据,属于读多写少的场景,数据量大,查询字段较固定,同时没有提供全文检索功能,考虑到降本等因素,最终选择的方案是mysql+hbase。其中mysql采取分库策略,存储查询的关键字组合+rowkey,hbase中保存文档的具体内容。
hbase非常适合存储PB级别的海量数据(百亿等级级条记录),如果根据rowKey来查询,能在几十到百毫秒内返回数据。另外,由于业务本身的特点,存放在hbase中的列属性主要包含两类数据,这两类数据适用于的业务场景也不同,列簇机制是最优选择。
总结
技术本身没有优劣之分,每种技术都是由业务决定的,最适合业务的技术才是最有价值的技术。
以上是关于数据迁移——技术选型的主要内容,如果未能解决你的问题,请参考以下文章