微服务架构深度释疑：如何选择数据库？
Posted 数字技术观察
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务架构深度释疑：如何选择数据库？相关的知识，希望对你有一定的参考价值。
往期回顾
在微服务架构中，没有哪个组件像数据库这般丰富多彩，百家齐放。关系型、非关系型、交易型、分析型、行式、列式、键值、文档、缓存、图、时序、全文搜索、......，各种新名词、新概念层出不穷，令人眼花缭乱，即便是数据库领域的从业者，有时也有一些无所适从的感觉。
本文篇幅很长，万字“雄文”，总结了我最近在数据库领域的一些思考和认知，也许有些地方不成熟，但胜在人会慢慢进步，与读者朋友们共享。
对于微服务架构而言，每个微服务都完成不同性质的业务功能，拥有不同的数据模型，采用不同的数据存储技术。例如，大并发高负载业务场景，选择内存数据库；大数据批量处理和即时查询场景，选择列式数据库；海量半结构化数据存储场景，选择文档数据库。
每一种数据库技术的出现，都是为了更好地适应业务数据的存取与处理，不存在普适意义上的谁比谁好，谁替换谁的问题。在某个特定的业务场景下，数据库类别的选型，对微服务的性能、可扩展性、可维护性都具有决定性的影响。
在移动/消费互联网背景下，如何才能正确地选择各种不同的数据库，最大化发挥其长处，归根结底，最重要的是了解这些数据库产品的定位，并且了解每个数据库的优劣势，继而在实际应用中做到扬长避短。
数据库类型的多样性，并非因为微服务架构而蓬勃，但一定会因为微服务架构而更加丰富多彩。
在数据库出现之前的1960年代，基本上没有专门的数据管理，所有的数据信息都以文件的形式存取，也就是“无库”年代。“无库”年代的数据管理有三个问题：
各个部门各自管理着自己的数据，无论是人事部，还是财务部和行政部，都制作自己的员工管理档案，给企业造成了严重的资源浪费（人力输入数据、硬盘存储数据、纸张存档数据）。
更为麻烦的是，如果新员工入职或老员工离职，企业必须人工通知所有部门更改各自维护的数据表。
人工通知各部门更新数据不仅是一件“折腾人”的事情，而且有可能通知成功了，但是人事部忘记更改了，或者财务部错误地把员工A听成了员工B。错误发生之后，各部门的数据就出现了不一致的“严重”情况，系统信息与现实情况相互矛盾。
当企业业务扩张时，需要从各部门抽调精干力量，增加一个战略部，负责管理战略级大客户和潜在客户关系的维护，如果能够利用目前已有的员工信息的话，就可以节省很多数据输入的时间。但是，目前正在使用的数据很难原封不动地被重复利用，因为员工数据由各部门分别管理和维护，战略部必须重新制作自己部门的员工信息档案。
无库之痛归根结底是由于数据管理的“烟囱式”造成的，要更高效地维护和使用数据，必须引入数据管理工具，对企业数据进行统一的管理，并在各个部门和各个应用之间共享数据。
1960年代后期，IBM公司开始研制一种名叫“数据库”的软件工具，数据库中的数据不再是面向某个部门或某个应用，而是面向整个企业（组织）或整个业务系统。
在数据库50多年的发展历史上，最初出现的网状数据库和层次数据库占有着重要的历史地位。
网状数据库和层次数据库都由指针（Pointer）连接数据，并表示数据之间的关系。所谓“指针”，就是表示数据在硬盘上的存储位置，所以，在使用这些模型的时候，首先必须知道数据在硬盘上的物理位置和存储结构，对于应用开发人员而言，使用门槛极高，灵活快速检索数据更是非常困难。到1980年代，这两种数据库逐渐被淘汰，取而代之的是风靡IT世界40年的关系型数据库（Relational Database）。
所谓关系型数据库，是指采用关系模型来组织数据的数据库。所谓“关系模型”，可以简单理解为二维表格模型，而一个关系型数据库就是由二维表格及其之间的关系组成的一个数据组织。
与网状数据库和层次数据库相比，关系型数据库具有如下优点：
1、结构简单
二维数据表很贴近我们的生活逻辑，相比较网状数据库和层次数据库，更容易理解关系模型的结构和内容。
2、接口标准
采用标准的SQL（Structured Query Language，结构化查询语言）对数据库进行增、查、改、删（Create、Retrieve、Update、Delete，简称CRUD）操作。
3、使用方便
关系数据模型中的存取路径对开发人员而言完全透明的，应用程序与数据具有高度的独立性，业务逻辑与后端数据完全解耦。
4、理论基础
以严谨的数学理论（关系代数）为基础，包括逻辑计算和数学计算，支持并（Union）、差（Difference）、交（Intersection）、笛卡尔积（Cartesian Product）四种集合运算和投影（Projection）、选择（Selection）、连接（Join）、除（Division）四种关系运算。
正是因为上述优点，使得关系型数据库迅速取代网状数据库和层次数据库，在数据库领域独领风骚四十载。
关系型数据库的典型产品包括Oracle、mysql、PostgreSQL、IBM DB2、Microsoft SQL Server等。时至今日，尽管非关系型数据库早已成为互联网应用的宠儿，但是，关系型数据库的热度依旧在DB-Engines数据库流行度排行榜上遥遥领先，在金融、电力、交通、医疗、运营商等关键行业应用中，依然具有不可替代的地位。
关系型数据库擅长少量数据的读写存储、复杂的SQL操作以及强一致性的事务机制。但是，最近5年，随着移动/消费互联网应用的爆发式发展，关系型数据库逐渐暴露出无法适应互联网时代的局限性：
1、海量数据的存取容量
以微信、QQ、今日头条、抖音、快手、B站、新浪微博等为典型代表的互联网应用每天都会产生海量的用户数据。以微信为例，微信每天发送的消息数量保守估计超过500亿条，如此海量的数据已经远远超出了关系型数据库的承载范围。关系型数据库单表支撑到千万级记录基本就到达瓶颈（例如，业界公认MySQL单表容量<1千万是最佳状态），必须通过分库、分表、多副本等多种方式解决。但是，这些复杂的工作需要有强大的数据库团队支撑，成本较高。
2、海量数据的存取性能
移动/消费互联网应用的用户并发性能要求极高，新浪微博之所以在“明星官宣”等爆炸性新闻出现时屡屡崩溃，可能的原因之一就是后端数据库对高并发场景支持能力不足，尤其是在写操作频繁的新浪微博场景。即便采用读写分离+分库分表等技术手段，也不能从根本上解决互联网应用如“黑洞”一般的性能要求，相反，还会引入数据不一致、联表查询或硬件高成本投入等新的问题。
3、多元化数据的存储
非结构化数据（文档、图片、音视频）是移动/消费互联网时代的主要数据源（行业公认占比已达互联网整个数据量的80%以上），虽然Oracle、MySQL、PostgreSQL、Microsoft SQL Server等关系型数据库对非结构化数据的存取做了大量的功能补齐工作，但是，由于非结构化数据的特点是没有预先定义好的数据模型，而传统关系型数据库又必须预先定义好表结构，这就使得传统关系型数据库在非结构化数据的存储和处理上始终处于竞争弱势地位。
4、容量/性能在线扩展
当一个业务系统的用户量和访问量与日俱增的时候，传统的关系型数据库没有办法简单地通过在集群中增加更多硬件和服务节点来扩展性能与负载能力，对于很多需要提供7*24小时不间断服务的系统来说，数据库的升级与扩展是一件极其痛苦的事情，往往需要停机维护和数据迁移。
5、读写实时性
关系型数据库十分强调数据的强一致性（参阅：），但是，为此所付出的巨大代价就是读写性能较差，尤其是面对海量的数据和高并发的业务场景，非常容易出现上一个事务没有处理结束，后续请求“蜂拥而至”导致雪崩效应。移动/消费互联网应用的需求恰恰相反，它们往往并不需要那么高的实时性，只需要保证数据的最终一致性即可，但是对并发读写要求极高。
6、表结构更新
在业务快速迭代的今天，对数据库表进行更新（如增加字段、修改字段属性、增加/修改索引等）是一个常见的需求，但是，对于关系型数据库而言，变更期间，需要对数据库表进行共享锁定，期间不允许变更数据内容（如插入、删除、更新等）。如果给数据量较大的表创建索引，或者变更表结构，将造成业务长时间无法更新数据内容。
非关系型数据库的历史要追溯到1998年，软件工程师Carlo Strozzi首次提出NoSQL的概念，用于命名他开发的一个没有SQL功能、轻量级、开源的关系型数据库。这个定义与我们现在对NoSQL的定义有很大的区别，在当时，它确确实实字如其名，指的就是“没有SQL”的数据库。但是，NoSQL的发展慢慢偏离了初衷，CarloStrozzi也发觉，其实我们要的不是“No SQL”，而应该是“No Relational”，也就是我们现在常说的非关系型数据库。
2009年6月，英国伦敦软件开发者Johan Oskarsson在旧金山组织了一次关于分布式开源数据库的技术聚会，来自Rackspace的Eric Evans再次提出了NoSQL的概念，这时的NoSQL主要指非关系型、分布式、不提供ACID的数据库设计模式。
Eric Evans使用NoSQL这个词，并不是因为字面上的“没有SQL”的意思，他只是觉得很多经典的关系型数据库名字都叫“**SQL”，为了表示跟这些关系型数据库在定位上的截然不同，就使用了“NoSQL”一词。
小知识
关系型数据库遵循的ACID原则
A：Atomicity（原子性）
数据库事务中的所有操作要么全部做完，要么什么都不做，事务成功的条件是事务中的所有操作全部成功，只要有一个操作失败，整个事务就失败，需要回滚。例如，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）往B账户存入100元。这两个步骤要么一起完成，要么一起不完成。如果只完成第一步，第二步失败，账户A的钱就会莫名其妙少100元。
C：Consistency（一致性）
数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。例如，现有完整性约束a+b=10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a+b=10，否则事务失败。
I：Isolation（独立性）
并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。例如，从A账户转100元至B账户，在这个交易还未完成的情况下，如果B查询自己的账户，是看不到新增加的100元的。
D：Durability（持久性）
事务一旦提交，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
NoSQL发展至今，已经演变成一个象征性的词汇，英文解释为“Not Only SQL（不仅仅是SQL）”，意思就是在SQL基础上衍生而来，相当于SQL的补充，但为了区分，故称为NoSQL数据库。
随着移动/消费互联网的兴起，NoSQL成为一个极度热门的新领域，产品种类发展非常迅速。据不完全统计，截至目前，已经有超过225种NoSQL数据库（https://nosql-database.org/），并且大部分都是开源的，而且它们有一个共同的特征，那就是与关系型数据库遵循ACID原则不同，NoSQL数据库遵循完全相反的BASE原则。
小知识
NoSQL数据库遵循的BASE原则
Basically Available（基本可用）
当数据库出现故障的时候，允许损失部分可用性，即保证核心可用，支持分区失败。例如，双11电商促销期间，为了应对激增的访问流量，部分用户可能会被引导到服务熔断页面，部分服务可能只提供降级服务，这就是损失部分可用性的具体体现。
Soft-state（软状态）
允许数据库状态在一段时间内不同步或异步，即允许系统存在中间状态，而这个中间状态不会影响系统的整体可用性。例如，分布式存储中，一般一份数据至少有三个副本，允许不同节点间副本同步的延时就是软状态的体现；MySQL Replication的异步复制也是一种体现。
Eventually consistent（最终一致）
数据最终保持一致即可，而不要求实时一致，即系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
在众多的NoSQL数据库中，我们将常用的数据库大致分成四种类型：列式数据库、键值数据库、文档数据库、图数据库。
| 类型 |
典型代表 |
特点 |
| 列式数据库 |
HBase Cassandra Vertica Teradata Greenplum |
方便存储结构化和半结构化数据，支持数据压缩，针对某一列或者某几列的查询具有非常大的I/O优势。缺点是功能相对局限。 |
| 键值数据库 |
Redis Memcached |
主要用做内容缓存，适用于大量小数据的高访问负载应用，也用于一些日志系统。缺点是存储数据缺少结构化。 |
| 文档数据库 |
MongoDB CouchDB |
数据模型自然，编程友好，数据结构要求不严格，无需预先定义表结构。缺点是查询性能不高，缺少统一的查询语法。 |
| 图数据库 |
Neo4j GraphDB |
专注于构建关系图谱，查询速度极快，适用于社交网络、推荐系统。缺点是需要整个图计算才得出结果，不容易做分布式集群方案。 |
既然有列式数据库，就一定有行式数据库。所谓“行式数据库”，是指按“行”的方式将每行的各个字段数据存储在一起，一行一行连续存储。Oracle、MySQL、PostgreSQL等关系型数据库都是行式数据库。
行式数据库很适合小事务和小查询的场景，单个数据库每秒处理的交易数量级别一般小于10万，典型的场景有金融和电子商务系统，一次取出一条或多条行记录。对于企业日常业务来说，这是非常合适的，因为我们在设计企业业务逻辑的时候，都是针对一个事务，将一个事务的所有属性都存储成一行，在使用的时候，也是很大概率涉及到整行的信息。
既然已经有了行式数据库，为什么还需要列式数据库呢？原因是行式数据库不适合于OLAP（Online Analytical Processing，在线分析处理）决策分析场景，例如数据仓库、数据集市、BI（Business Intelligence，商业智能）等。
OLAP的本质是从多个维度的灵活组合来观察数据，从而发现数据内在的规律，例如，统计各部门的销售收入和利润同比变化。这种统计分析场景是在行记录的某些字段上的操作，但是，行式数据库的处理方式是从头至尾逐行读取数据，在仅分析销售收入和利润的时候，把每一条数据库记录的所有其他字段（如项目名称、渠道商、签约时间等）统统都读入内存，不仅耗时，而且浪费了大量内存资源和I/O资源。
当然，我们可以为每个记录建立“索引”，就像大型商场中的导购牌一样，做到快速定位，但是，随着数据量越来越大，分析场景越来越复杂，大量的索引带来的存储空间的浪费以及维护这些索引所带来的时间成本都会以指数级别增长。
为了解决统计分析场景下的数据库查询性能问题，引入了列式数据库。列式数据库的思路是将行式数据全部拆开，按照列的方式重新组合存储，一列的所有行的数据存放在一起。
列式存储带来如下两个价值：
1、高效读取
当需要分析某个部门的销售收入和利润同比增长的时候，只需要读取部门编码、销售收入和利润三列的字段，而不需要读取多余的无关数据，消除无关列的扫描，节省内存空间和磁盘I/O，同时，在复杂、多表关联、历史数据分析的场景下，比传统的行式数据库快成百上千倍。
2、高效压缩
按照列内数据的特征值进行高效编码，例如，部门编码、签约时间、渠道商等维度的字段特征值并不多，几个或几百个，在实际存储的时候，可以以编码形式存储，带来大比例的压缩。目前，可公开的、最大的数据仓库压缩后的数据量达几百TB，约合传统行式数据库几PB的总量数据压缩比达10倍左右。
企业数据分析中最困难的随机查询场景，是列式数据库的长项。列式数据库在数据仓库、数据集市、BI等领域已经发挥了越来越多的作用，目前，各个传统数据库厂商都以不同的形式在接受列式存储技术，使传统行式数据库具有双模数据存储方式，从而能够实现对混合类型应用的支持，例如，Oracle 12c In-Memory组件、Microsoft SQL Server 2012中的ColumnStore Index列存储索引技术等。
最后，需要说明的是，列式数据库可以是关系型数据库（例如：Vertical、Teradata、Sybase IQ/SAPIQ、Greenplum等），也可以是NoSQL（例如：HBase、Cassandra等）。
在传统的业务系统架构中，前端业务直接访问后端数据库，在访问量较小的场景下，整个系统能够保证业务的流畅性。但是，在大并发、高负载的互联网应用中（每秒访问量超过万次），后端数据库的性能是无法支撑的，尽管可以通过索引、分库分表、读写分离等技术手段部分缓解数据库压力，但是这些技术手段除了增加数据库的复杂度之外，并不能从根本上解决问题，当访问量继续加大的时候，数据库仍然会面临崩溃的风险。
为了解决传统关系型数据库在大并发、高负载场景下的访问性能问题，出现了内存数据库。
所谓“内存数据库”，就是将经常使用的数据存放在内存中，减少前端业务与后端数据库之间的交互频率，提升数据访问速度。
内存数据库是一个大的概念，包括关系型内存数据库和键值型内存数据库。
Oracle TimesTen、SAP HANA、MySQL Memory Engine、Microsoft SQL Server 2016 In Memory OLTP等属于关系型的内存数据库引擎，通过内存缓存提高应用事务的响应时间。关系型内存数据库一般都是商业闭源软件，价格比较昂贵，同时，数据管理仍然采用常规的关系型数据库表的管理方式，拥有与传统关系型数据库一样的ACID特性，比如事务的原子性和持久性，在面对互联网式的大并发、高负载应用流量时，性能与可扩展性仍然是突出的问题。
键值数据库完全基于内存操作，没有磁盘I/O瓶颈，这是键值型内存数据库性能优秀的主要原因。
在DB-Engines数据库流行度排行榜上，Redis是当前最主流的键值型内存数据库，由意大利人Salvatore Sanfilippo开发，从2009年发布第一个版本开始，已经走过了10+个年头，至今仍然是最受欢迎的Key-Value型内存数据库。当然，优秀的开源项目离不开大公司的支持，在2013年5月以前，Redis开源项目由VMware赞助，2013年5月至2015年6月期间，由Pivotal赞助，从2015年6月开始，Redis的开发由Redis Labs赞助。
Redis的全称是Remote Dictionary Server（远程数据服务），使用C语言编写，具有如下几个特征及场景。
1、丰富的数据类型
Redis开发了一套独有的基础数据结构，基于这些数据结构，支持Strings（字符串）、Hashes（哈希）、Lists（列表）、Sets（集合）、Sorted Sets（有序集合）、HyperLogLog（基数）、Bitmaps（位图）、Geospatial Indexes（地理空间索引）、Streams（流）等九种数据类型。
在新浪微博、今日头条、抖音等应用中，数据类型已不再局限于传统的字符串形式，出现了“关注列表”、“粉丝列表”、“点赞数”、“评论数”、“转发数”、“浏览数”、“热门排行榜”等新的数据类型，传统的关系型数据库不太适合存储和查询此类数据类型，而Redis提供的Hash类型特别适合于互联网应用的点赞、评论、转发、浏览等属性的存储与查询；Sorted Set类型特别适合于发帖排行榜、阅读排行榜、点赞排行榜等类型数据的存储和查询。
2、会话状态保持
绝大多数互联网应用都基于B/S架构，浏览器采用HTTP协议与服务端通信，浏览器首次访问服务端的时候，服务端会响应一个SessionID，并把这个SessionID传输给浏览器，以Cookie保存在浏览器本地。之后的访问会将SessionID以请求头的方式传给服务端，服务端用这个SessionID查找对应的用户，这样就能标识出用户是谁了。这种架构本质上是客户端本地保存SessionID，服务端保存SessionID与用户信息映射，这样就实现了Web应用的有状态化。
但是，在微服务等分布式架构中，后端业务系统往往通过集群负载均衡的方式解决大并发访问的性能问题。浏览器首次访问服务端的时候，负载均衡器会将流量分担到服务器A，下一次访问的时候，流量有可能被分担到服务器B，而服务器B并没有用户与SessionID的映射关系，就会认为用户没有登录，从而要求用户重新登录，这就是Session不一致的问题。
解决Session不一致问题的终极方案是Session存储与应用分离，即将Session存储在一个独立的数据库，客户端传入SessionID的时候，在数据库中查询SessionID与用户的映射关系，既解决了Session保存在客户端本地的安全性问题，又解决了分布式场景下的Session不一致问题。
Redis普遍的应用场景就是Web应用的Session状态保持，将原本无状态的HTTP协议通过Session的集中管理实现Session在分布式场景中的共享。
除了Redis之外，还有一款较为主流的键值型内存数据库：Memcached。但是，由于Memcached在数据类型支持方面单一（仅支持最简单的Key-Value）、不支持数据持久化（服务重启时数据丢失）、不支持服务端分布式等问题，市场接受度已完全被Redis远远甩在身后，尤其是在BAT等大型分布式场景中，Redis已取代Memcached成为最热门的键值型内存数据库。
Redis内存数据库的读写速度非常快，丰富的数据类型也非常具有吸引力，但是，它最大的问题是存储能力受限于物理内存容量，在大容量数据存储场景显得力不从心，尤其是对于需要存储图片、音频、视频等非结构化数据的场景，例如新闻网站、购物网站等。此时，文档型数据库可能就是您的最佳选择。
目前，最主流的文档型数据库非MongoDB莫属。
MongoDB是概念上最接近关系型数据库的NoSQL，不同的是，它是一个Schema-Free的文档数据库，面向的是集合（Collection）而不是表，所有的数据存储都以集合为单位，每个集合里面包含的数据则称之为文档（Document），一个集合中可以包含无数个文档，每个文档可以大致认为是一个JSON数据模型，而且，集合中的每个文档并不要求数据严格一致（Schema-Free），可能是千差万别的。比如，上一个文档有3个属性，下一个文档可能有5个属性，属性的类型可以是数字、字符串、日期等基本的数据类型，也可以是数组或者Hash，甚至还可以是一个嵌套的子文档。
除了灵活的数据模型，MongoDB还有一个特色，它的查询能力非常强大，几乎可以实现关系型数据库的绝大多数功能，更有特点的是，MongoDB操作数据库时不采用难以记忆的SQL语法，而是直接使用JSON风格语法，客户端提交或接收到的数据都以JSON形式呈现，相对于SQL来说，更加直观易用，更容易理解和掌握。
为应对海量数据的存储需求与查询需求，MongoDB支持集群水平扩展模式，结合分片（Sharding）技术和副本集（Replica Sets）技术，在确保数据分片到多个服务器的同时，也确保每个数据分片都有相应的备份。
一个典型的MongoDB集群架构会同时采用分片+副本集的方式：
查询路由（Query Routers）：MongoDB自带的专有路由进程，客户端由此接入，将客户端发来的请求路由到集群中的一个或一组服务器上，同时，将接收到的响应拼装返回给客户端，让整个集群看上去像单一数据库，前端应用可以透明使用。Query Router本身并不持久化数据，MongoDB集群可以部署多台Query Router以分担客户端请求的压力。
配置服务器（Config Servers）：保存集群的元数据（Meta Data），包括各个分片数据的路由信息。默认需要配置3个Config Server节点。
数据分片（Shards）：真正的数据存储位置，以“chunk”为单位存储数据（默认64MB），在实际生产环境中，一个Shard Server角色由几台机器组成一个Replica Sets承担，防止单点故障。
MongoDB最直观的一个应用场景就是微博系统的评论区管理。一个热门的微博，例如白百何出轨、乔任梁去世等，评论区的数据量会非常大，在打开微博的时候，评论区内容的查询要控制在极短的时间内以提升用户体验。MongoDB可以将微博内容与评论设计为一个集合，评论作为子文档嵌入，而评论的回复则作为子文档的子文档嵌入。
按照这种设计模式，只需要根据微博ID检索一次，即可获得所有相关的信息。如果评论量超过默认的分片大小，则通过MongoDB分片机制，将海量的数据查询分担到不同的分片服务器上，最后将查询结果整合在一起。
随着社交、电商、金融、零售等行业的快速发展，现实社会织成了一张庞大复杂的关系网，在数据量呈几何级数增长的今天，互联网、零售、金融等行业都亟需一种支持海量复杂数据关系运算的数据库，用于深度挖掘已有数据之间的关联关系，例如：
社交：Facebook、Twitter、Linkedin用它来管理社交关系，实现好友推荐。
零售：eBay、沃尔玛使用它实现商品实时推荐，给买家更好的购物体验。
金融：摩根大通、花旗和瑞银使用它实现反欺诈和风控处理。
满足这些需求的数据库就是图数据库（Graph Database）。
所谓“图数据库”，并非存储图片的数据库，而是以“图”这种数据结构存储和查询数据。
“图”由两个元素组成：节点和关系。每个节点代表一个实体（人、地、事物、类别或其他数据），每个关系代表两个节点的关联方式。这种通用结构可以对各种场景进行建模，如社交网络以及由关系定义的任何其他事物。
在现实生活中，图结构是非常复杂的，而且数据量很大，经常需要做各种各样的分析，所以，图数据库一般在文件系统上单独存储了标签和属性，就是为了在做检索和分析的时候保证性能。下面以一个形象的例子说明什么是标签，什么是属性。
下面是一个实际案例，查询一个具有标签为 “沪深股市”，且有一个属性对“{name: "sha_600610"}”的节点，然后查找这个节点的所有双向关系，在这些关系的中，要求另外一个节点具有“人物_公司股东”这个标签，返回这个节点以及满足要求的关系和相关节点。
图数据库善于处理大量的、复杂的、互联的、多变的网状数据，适用于社交网络、实时推荐、银行反欺诈、金融征信系统等领域，其效率远远高于传统的关系型数据库。
毫无疑问，NoSQL在各种特定场景下提供的灵巧设计和极致性能让我们倍感兴奋和激动，以MongoDB为代表的数据库厂商也在多种场合展现出了替代Oracle和DB2的“野心”，但是，关系型数据库作为一种影响深远、历经考验的标准化技术，不可能立即被NoSQL所替代。
除了ACID等事务处理的技术优势之外，标准化是关系型数据库相比较NoSQL的最大优势，200+种NoSQL技术各自为政，缺乏一种主导力量，就像战国时期的齐、楚、燕、赵、魏、韩等诸侯国，始终难以对秦国造成实质性的威胁，在电信、金融等关键核心生产系统中，关系型数据库依然具有无可撼动的坚实地位。
在移动/消费互联网时代，数据的多元化催生了NoSQL的多元化，如何才能正确地选择各种不同的数据库，最大化发挥其长处，归根结底，最重要的是了解这些数据库产品的定位，并且了解每个数据库在各种场景的优劣势，继而在实际应用中做到扬长避短。
以上是关于微服务架构深度释疑：如何选择数据库？的主要内容，如果未能解决你的问题，请参考以下文章