四种分布式数据库的场景选型和优缺点分析
【摘要】随着互联网金融场景的不断拓展，海量的数据访问和处理造成传统的集中式数据库开始表现出性能瓶颈，分布式数据库的研究和场景使用应运而生，而数据的安全和合规也随着企业对数据使用的要求越来越高更加重视。因此在这种场景下，分布式数据库应具备高性能、可扩展、高可用和高容错等特性，而传统的集中式数据库难以同时满足，本文重点介绍分布式数据的特性及种类，根据相应的业务场景对分布式数据库选型进行分析，并对分布式数据库的细分领域的发展进行探讨。【作者】顾黄亮，十年技术老兵，历经研发和运维，了解基础架构、安全、中间件、数据库，专注于智慧运维体系的打造。曾供职于航天晨光、上汽集团云计算中心，现任苏宁消费金融安全运维部总监。
1 引言
近年来，随着国际信息安全形式的日益严峻，国家信息安全策略逐步深入。因此，一行两会连续针对金融业数据库技术受制于人的严峻形势出台了相关政策，以满足构建安全可靠可控的信息技术体系的要求。
纵观近年来普惠金融的发展，多用户、低额的客单价带来的主要挑战是数据量、交易额的大幅提高，并伴随着数十倍的交易高峰压力以及交易复杂度的增加。而传统数据库在处理此类应用场景的时，在扩展性、性能、吞吐量和可靠性等方面遇到了明显的瓶颈，只能通过业务拆分、升级硬件的方式来提升性能，造成设备投入和人员成本的不断攀升。面对着互联网金融业态不断的发展，数据的交互和存储也呈现指数级增长，这样的方式也无法保证业务连续性。在此形式下，在分布式数据库的选型上，根据不同的业务场景和关键系统中选择不同的开源产品，通过对开源数据库的深入研究和应用，满足了互联网金融业务场景的事务处理和数据处理的要求。
2 传统数据库的那些事
个人认为，分布式数据库是起源于传统的关系型数据库，两者的设计场景不同，前者面对企业级应用，运行在独立的服务器上，而后者的应用更多的是面对互联网用户。随着用户相应的数据量极具增加，传统的关系型数据库在可扩展性的弊端日益显现，一般有下面几个方面：
（1）单点处理的性能瓶颈，即单点的数据库系统无法处理大规模的并发请求和计算；
（2）单点运行风险高，容灾容错能力差；
（3）单点存储能力有限，只能纵向扩展，不能横向扩展；
（4）应用扩容升级难度大，设备投入高。
对于数据库本身来说，传统的分布式数据库都有各自的集群解决方案，不过这不是真正意义上的分布式，仅仅是为了解决高可用场景下数据库的负载均衡问题。这种特性是每个数据库都是冗余的，所谓冗余，那就是每个数据库的数据都是完全一样的，所以数据量上升到一定的程度，对集群中的每个数据库都会造成很大的压力。
然而，云计算的出现引爆了这一切。当资源不再是瓶颈的时候，分布式数据库的春天来了。
3 说说分布式数据库
分布式数据库的概念不再阐述，大体描述就是数据库技术和网络技术的亲生孩子。在此，我们为什么选择分布式数据库，理由有如下：
（1）具有灵活的体系结构；
（2）适应分布式的管理和控制机构；
（3）经济性能优越；
（4）系统的可靠性高、可用性好；
（5）局部的应用响应快；
（6）优越的可扩展性，易于集成现有的系统。
那分布式数据库应该怎么用？基于分布式数据库的选型该怎么做？
首先，基于特性，分布式数据库大致可以分为三类：
（1）支持持久化存储的分布式存储系统，如MySQL，OceanBase；
（2）偏向于计算的分布式计算框架，如Hadoop HDFS，Ceph，Swift，Blob，Cinder，Lustre；
（3）分布式消息队列，如Redis，RMQ，CMQ，Kafka。
其次，基于不同的应用场景，根据特性继续细化，又可以分为以下：
（1）分布式协同数据库系统；
（2）分布式任务；
（3）流式计算；
（4）分布式文件系统；
（5）分布式nosql存储；
（6）分布式关系数据库；
（7）分布式消息队列。
回到最核心的问题，如何进行分布式数据库技术路线的选择？
分布式一般分为三条技术路线：分布式访问客户端、分布式中间件模式、分布式数据库模式。其中分布式访问客户端对应用侵入性大，改造难度很高；分布式中间件则类似MyCAT等产品，在数据库和应用间架一层Proxy，这种方案无法支持分布式事务、也无法支持跨库关联，分布式数据库方案则将分库分表等中间件实现的功能下推到数据库层面来做，对应用透明，应用就像使用单机数据库来使用分布式数据库，同时天然地支持分布式事务。
4 常用的分布式数据库和场景选型
针对以上概述，列举ElasticSearch、Redis、MySQL分布式集群、MongoDB四个分布式数据库进行举例，分别从简介、应用场景、优点、缺点、备份/持久化进行对比和分析。其中MySQL分布式集群包括以下几种集群方式：Proxy，Cluster，Mha，Mgr，基于MySQL协议的NewSQL，如MyCAT，OceanBase不在此范围之内。
（1）简介
简介 | |
ElasticSearch | Elasticsearch是分布式的实时文件存储，每个字段都被索引并可被搜索，分布式的实时分析搜索引擎，可以扩展到上百台服务器，处理PB级结构化或非结构化数据 |
Redis | Redis是开源BSD许可高级的key-value存储系统(NoSQL)，可以用来存储字符串，哈希结构，链表，集合，因此，常用来提供数据结构服务，Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加 载进行使用。 支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。Redis支持数据的备份，即master-slave模式的数据备份。 |
MySQL分布式集群 | MySQL集群是一个无共享的(shared-nothing)、分布式节点架构的存储方案，其目的是提供容错性和高性能。数据更新使用读已提交隔离级别（read-committedisolation)来保证所有节点数据的一致性，使用两阶段提交机制（two-phasedcommit)保证所有节点都有相同的数据(如果任何一个写操作失败，则更新失败）。 |
MongoDB | MongoDB本身是一种非关系型数据库。它的每一条记录是一个Document，每个Document有一组键值对组成。MongoDB中的Document与JSON对象相似。 Document中字段的值可能包括其他Document，数组等。 |
（2）应用场景
应用场景 | |
ElasticSearch | （1）分布式的搜索引擎和数据分析引擎，全文检索，结构化检索，数据分析；（2）对海量数据进行近实时的处理，站内搜索（电商，招聘，门户，等等），系统搜索，数据分析 |
Redis | （1）常规计数：粉丝数，微博数（2）用户信息变更（3）缓存处理，作为主数据库的缓存（4）队列系统，建有优先级的队列系统 |
MySQL分布式集群 | （1）多库冗余；（2）水平切分表；（3）自定义分库分表方案；（4）分布式管理器 |
MongoDB | （1）网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性；（2）缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载；（3）大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储；（4）高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库；（5）用于对象及JSON数据的存储：mongo的BSON数据格式非常适合文档格式化的存储及查询。 |
（3）优点
优点 | |
ElasticSearch | （1）将你的文档分割到不同容器或者分片中，可以存在单个节点或多个节点；（2）复制每个分片提供数据备份，防止硬件问题导致数据丢失；（3）对集群中任意节点的相互请求进行路由，保证获取的数据是你需要的，集群增加或者重新分配分片时，不停机让新节点恢复丢失的节点分片数据 |
Redis | （1）速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；（2）支持丰富数据类型，支持string，list，set，sorted set，hash；（3）支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行；（4）丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除 |
MySQL分布式集群 | （1）高可用性；（2）快速的自动失效切换；（3）灵活的分布式体系结构，没有单点故障；（4）高吞吐量和低延迟；（5）可扩展性强，支持在线扩容 |
MongoDB | （1）弱一致性（最终一致），更能保证用户的访问速度；（2）文档结构的存储方式，能够更便捷的获取数据；（3）内置GridFS，支持大容量的存储；（4）在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比MySQL慢，而对非索引字段的查询，则是全面胜出 |
（4）缺点
缺点 | |
ElasticSearch | 没有用户验证和权限控制，没有事务的概念，不支持回滚，误删不能恢复，需要java环境. |
Redis | 主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦 |
MySQL分布式集群 | （1）存在很多限制，比如：不支持外键；（2）部署、管理、配置很复杂；（3）占用磁盘空间大，内存大；（4）备份和恢复不方便；（5）重启的时候，数据节点将数据load到内存需要很长时间 |
MongoDB | （1）不支持事物；（2）占用空间过大，会造成磁盘浪费；（3）单机可靠性比较差；（4）大数据量持续插入，写入性能有较大波动 |
（5）备份/持久化方案
备份/持久化方案 | |
ElasticSearch | gateway 代表 ElasticSearch 索引的持久化存储方式，ElasticSearch 默认是先把索引存放到内存中去，当内存满了的时候再持久化到硬盘里。当这个ElasticSearch 集群关闭或者再次重新启动时就会从 gateway 中读取索引数据。ElasticSearch 支持多种类型的 gateway，有本地文件系统（默认），分布式文件系统，Hadoop 的 HDFS 和 amazon 的 s3 云存储服务。 |
Redis | Redis提供两种方式进行持久化，一种是RDB持久化（原理是将Redis在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。 |
MySQL分布式集群 | （1）负载均衡；（2）二进制文件备份 |
MongoDB | 当执行写操作时，MongoDB创建一个journal来包含确切磁盘位置和改变的字节。因此，如果服务器突然崩溃，启动时，journal会重放崩溃前并没有刷新到磁盘上的任何写操作。数据文件每隔60s刷新到磁盘上，默认情况下，因此journal只需要持有60s内的写入数据。journal预分配了几个空文件用于此目的，位于/data/db/journal，命名为_j.0,j.1等等。 |
5 项目中的一些问题
在项目中，针对分布式数据库的设计，一般有几个难点。
（1）分布式事务的问题，在分布式数据库中，分布式事务的实时一致性是很难保证的，而容错性的设计一定要考虑全面，通过牺牲相应的可用性来保证一致性。
（2）性能方面，为了保证事务的全局一致性，分布式数据库需要一个全局的事务管理器，用于分配全局事务的工作，不同的分布式数据库或许有不一样的功能，如果数据量和请求达到一个量级的时候，事务管理器或许就成为一个新的瓶颈。
（3）高可用的问题，当分布式数据库集群中有节点宕机的时候，宕机数量和选举工作会影响整个集群提供服务的质量，这一点跟业务的容忍性密切相关。
在运维阶段，针对分布式数据库是从认识、熟悉到经过的过程，一个新的产品或者功能的运维是离不开很多准备工作。因此，进入运维阶段，一般要考虑下面几步。
（1）准备好常用的运维脚本、应急手册、运维手册；
（2）做好分布式数据库的监控，尤其是关键指标的监控；
（3）技术手册的培训，准入条件的限制；
（4）定期做好演练工作，及时发现问题。
6 分布式数据库发展的一些思考
在企业中，对于新技术新产品的选型不仅仅为了满足当前业务场景的需求，还要考虑到这个产品未来三到五年的发展道路和方向，以及是否能够不断迭代以满足未来的需求。因此，用户仅了解每一种技术的现状是远远不够的，只有当认识到一种技术的发展策略以及其架构的局限性后，才能够预见和洞察未来。架构局限性并不等于功能的缺失。很多新型技术 在开始时都无法提供像Oracle一样完备的企业级功 能，但并不意味着用户必须要等到全部功能完备后才 开始考虑学习和使用。用户在评估一种新产品和技术时，产品的功能点需要满足几个必备的基础功能，而一些高级功能则不需要立刻具备。
对于分布式数据库来说，随着业务场景和数据的使用处理方面的需求趋于成熟和明朗，分布式数据库的以场景和功能的区分更为细化，主要发展发现基本可以分为分布式联机数据库和分布式计算数据库两种，而针对非结构化小文件需求也在考验分布式数据库是否在这个领域能够打出一片天地，可以展望，小型的分布式的针对非结构化的文件存储数据库也可能后期的战场之一。
原题：分布式数据库的场景选型及趋势分析解读 如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
相关推荐：
欢迎关注社区 "分布式数据库"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/37323
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场