高性能标准网站建设进阶指南 pdf,网站 短链接怎么做,房地产销售平台网站建设,面点培训学校哪里有日常我们在开发中#xff0c;随着业务需求的变更#xff0c;重构系统是很常见的事情。重构系统常见的一个场景是变更底层数据模型与存储结构。这种情况下就要对数据进行迁移#xff0c;从而使业务能正常支行。 背景如下#xff1a;老系统中使用了mongo数据库#xff0c;由… 日常我们在开发中随着业务需求的变更重构系统是很常见的事情。重构系统常见的一个场景是变更底层数据模型与存储结构。这种情况下就要对数据进行迁移从而使业务能正常支行。 背景如下老系统中使用了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相当于把逻辑的一张大表按照列族分拆成若干小表分别进行存储对于行簇当达到一定数量后也会再被拆分这种存储特性带来了海量数据规模的支持和极强的扩展能力。缺点就是对于复杂的查询如查询条件涉及多列或无法获取查询的rowKey时查询效率是相当低下的。 优点 (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方式异步实现。
HBaseClickHouse数据存储Zookeeper保存元数据将数据写入HDFS中非结构化的数据Zookeeper保存元数据数据存储在本地且会极致压缩查询使用Phoenix协助处理器高效的查询能力数据读写支持随机读写删除。更新操作是插入一条新的timestamp的数据支持读写但不能删除与更新数据迁移方案 在mongo数据迁移的过程中上述哪一种存储方案都存在缺点即然一种存储方案都不能有效解决最好的方式就是组合吸取每种存储的做点。目前存储在mongo的数据属于读多写少的场景数据量大查询字段较固定同时没有提供全文检索功能考虑到降本等因素最终选择的方案是mysqlhbase。其中mysql采取分库策略存储查询的关键字组合rowkeyhbase中保存文档的具体内容。 hbase非常适合存储PB级别的海量数据(百亿等级级条记录如果根据rowKey来查询能在几十到百毫秒内返回数据。另外由于业务本身的特点存放在hbase中的列属性主要包含两类数据这两类数据适用于的业务场景也不同列簇机制是最优选择。 总结 技术本身没有优劣之分每种技术都是由业务决定的最适合业务的技术才是最有价值的技术。
