摘要：多花功夫，“因地制宜”选择最适合的数据库很重要。
互联网+AI时代，随着业务场景越来越复杂，各种开源和商业数据库品类繁多，让不少开发者眼花缭乱，无从下手。
业界有句俗语，任何脱离业务来谈架构都是瞎扯。所以用户在数据库选型时，需要从自身业务架构、业务数据量、数据类型、甚至团队成员的业务能力等多角度平衡，考量应该选择何种数据库。
那么，我们到底该如何根据每种数据库的特性选择最适合自己业务的？
强调事务，选它
首先谈谈应用最广泛的关系型数据库，关系型数据最大的特点便是事务，它能保证数据始终如一的一致性，这里就不得不提及一下事务的ACID特性：
原子性：事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生，不存在只执行了其中某一个或者某几个步骤。
一致性：事务执行后，数据库状态与其业务规则保持一致。如转账业务，无论事务执行成功与否，参与转账的两个账号余额之和应该是不变的。
隔离性：多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
持久性：在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，不会因为异常、宕机而造成数据错误或丢失。
另外，通用的SQL语言使得操作关系型数据库非常方便，支持join等复杂查询。
根据它的特点，关系数据库的适用场景通常可以分为OLTP和 OLAP。
其中，联机事务处理（OLTP）存储/查询业务应用中活动的数据，以支撑日常的业务活动，是每个企业不可或缺的生产交易系统。这类型应用数据量普遍不大，强调实时、快速响应、数据强一致性，比如银行存取钱，购物消费。
联机分析处理（OLAP）存储历史数据以支撑复杂的分析操作，侧重于决策支持，这类应用数据量大，高并行、低并发，可用性要求不高，比如客服系统，销售系统等。
以MySQL为例，这是当前最流行的开源关系型数据库，也是OLTP场景的首选数据库。
华为的GaussDB(for MySQL)和GaussDB(openGauss)核心竞争力也是OLTP的处理能力，同时具备一定的OLAP的处理能力。
但是通常不建议把OLTP和OLAP业务完全混合，在典型的OLAP处理场景就应该使用面向OLAP设计的数据库，而在典型的OLTP处理场景就使用面向OLTP设计的数据库，否则既达不到OLAP的扩展性，又无法满足OLTP的实时、高性能等要求。
需要强调的是，特别不建议基于OLAP去增加TP的能力，因为后者是实时和在线，而AP更多是分析，OLAP的数据库往往无法达到性能要求，即便上线初期看似能满足要求，但随着业务量的增加，问题就会凸显出来。
除此之外，还要根据是否支持JSON格式、支持的存储模式等维度评估，细节很多，所以在根据业务场景选择数据库的时候，一定要慎之又慎，灵活变通。
最后在具体业务场景方面，安利以下华为云的数据库产品。
网站业务：网站业务请求写少读多，可使用云数据MySQL只读实例水平扩展读负载能力，搭配分布式数据库中间件DDM使用，实现自动读写分离和读负载均衡。
移动应用：包含定位功能的移动应用可使用云数据库Postgre SQL数据库获得位置运算能力；数据庞大的移动应用，搭配DDM使用华为云RDS MySQL数据库，轻松应对分库分表问题。
游戏业务：爆发式增长的玩家数据存储和读写请求，可以使用华为云RDS快速扩容存储，变更规格或部署新的游戏分区数据库；游戏数据存档或回退，可使用华为云RDS自动备份和PITR特性随时闪回到任意时间点。
电商业务：电商“秒杀”、“抢购”等高并发的数据库请求，可使用华为云RDS高规格实例；业务连续性要求高的电商业务，可使用华为云RDS双机热备，跨AZ部署获得更高可用性支持。
金融业务：金融级业务连续性和数据可靠性要求，可使用华为云RDS双机热备，跨AZ部署，或者华为自研的分布式数据库的GaussDB，确保服务高可用，数据多副本存储和强一致性；金融级安全合规要求，可搭配数据库安全服务DBSS使用，实时监测并拦截SQL注入，防脱敏数据泄露，审计数据库日志。
针对特定场景，满足高并发读写，选它
关系型数据库虽好，但在很多方面也有些力不从心。比如面对高并发读写需求时，多表的关联查询、复杂的数据分析类型，为了保证ACID特性而牺牲的性能问题就凸显出来了。
这种时候，就是非关系型数据库的天下了。
NoSQL不再将数据的一致性作为重点，它针对特定场景，以高性能和使用便利为目的。目前，应用比较广泛的非关系型数据库有以下几种：文档数据库、key-value数据库、列存储数据库、时序数据库和图数据库。
文档数据库：
文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，如字符串、数字和日期等；也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。
代表产品：MongoDB、CouchDB、RavenDB
适用场景：
1. 日志：企业环境下，每个应用程序都有不同的日志信息。文档数据库并没有固定的模式，我们可以使用它储存不同的信息。
2. 分析：因为它的弱模式结构，所以不改变模式下就可以储存不同的度量方法以及添加新的度量。
备注：以MongDB为例，其使用场景很大程度上可以对标关系型数据库，但是比较适合处理那些没有join、没有强一致性要求且表Schema会常变化的数据。
键值数据库：
键值数据库就像在传统语言中使用的哈希表。可以通过key来添加、查询或者删除数据，鉴于使用主键访问，所以会获得不错的性能及扩展性。它的优势在于简单、易部署、高并发。
主流代表产品：Riak、Redis、Memcached
适用场景：储存用户信息，比如会话、配置文件、参数、购物车等等，具体包括游戏场景中的角色信息、经验道具信息、好友排名，电商场景中的海量商品展示信息、购物评论信息等，这些信息一般都和 ID（键）挂钩，所以键值数据库是个很好的选择。
列存储数据库：
列存储数据库将数据储存在列族中，一个列族存储经常被一起查询的相关数据。举个例子，如果有一个Person类，我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下，姓名和年龄就会被放入一个列族中，而薪资则在另一个列族中。
代表产品：Cassandra、HBase
适用场景：
1. 日志：可以将数据储存在不同的列中，每个应用程序能够将信息写入自己的列族中。
2. 博客平台：储存每个信息到不同的列族中，举个例子，标签可以储存在一个列族，类别、文章也可以分别存储在不同的列族。
时序数据库：
时序数据库就是存放时序数据的数据库，它需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。对比传统数据库仅仅记录了数据的当前值，时序数据库记录了所有的历史数据。它的查询也总是会带上时间作为过滤条件，数据以时间流的方式存在，每条记录包括时间戳。可以更加高效快速的存储大量时间序列数据并对这些数据进行实时分析。
代表产品：Prometheus、InfluxDB和OpenTSDB
适用场景：IoT传感器时序数据分析；证券及加密货币交易数据；软硬件设备实时监控；都市环保数据采集等等。
图数据库：
数据以图的方式储存。实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，Steve Jobs、Apple和Next，则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs。
代表产品：Neo4J、Infinite Graph、OrientDB
适用场景：
1. 在一些关系性强的数据中，用于构建关系图谱，例如社交网络。
2. 推荐引擎。如果我们将数据以图的形式表现，会非常有益于推荐的制定。
在非关系型数据库服务领域，华为云也推出了GaussDB(for Mongo)、GaussDB (for Redis)、GaussDB (for Influx)、GaussDB(for Cassandra）。目前，GaussDB(for Mongo)、GaussDB(for Cassandra)、GaussDB (for Redis)已正式商用，开发者可以根据不同的数据模型和处理逻辑来选择与业务相符的数据库。
最后：
举个简单例子，如果你的业务有大量的结构化数据且存在许多事务性操作，那首选肯定就是MySQL这样的数据库。
如果你的业务经常有突发的流量高峰，则优先考虑适用MangoDB这样的非关系型数据库，有比较好的扩展性。
数据库的选择决定了业务的可持续发展，所以一定要多花功夫，“因地制宜”根据业务实际情况，选择最适合的数据库。（注：文章中部分概念性内容源自网络。）