当有人问：数据库分哪几类？
我们通常的回答是：关系型的和非关系型的。
这个答案没毛病，但是略显简单粗暴。如果深究一下，非关系型数据库还有很多种型。
有种分类方法，把数据库分成了 8 个大类：你没看错，是数据库库库库库库库库！
为什么要分这么细呢？因为时代不同了，现代化应用对数据处理的要求越来越苛刻。
传统的关系型数据库，发展了几十年，遵从 ACID 原则，强关联、数据一致性，擅长事务处理。
事务处理这个功能很重要，比如用银行卡转账，必须保证对方账户钱增加的同时，而你的账户对应地减少了，中间出了差错，数据库就要“回滚”。
多少年来的金融级交易，都离不开关系型数据库的支撑，而企业大量的 ERP、CRM 系统，都是靠关系型数据库扛着的。
可是，随着社交、电商、IoT 等业务和应用蓬勃发展，数据尤其是非结构化数据爆发增长，传统关系型数据库有点独木难支。
于是，数据库进入了八仙过海，各显神通的时代，不同的数据库在各自的岗位上，提供了独特的价值。
举个例子，在电商的场景下，用户的主要身份信息账号密码等，一般存在关系型数据库里。
但用户的“购物车”，有人放了 1 件商品，有的剁手党可能会放 100 件商品，用关系型数据库存储就很不灵活。
这时候，键值数据库就派上了用场，用“键值对”来存储用户的购物车信息，水平可以任意扩展。
再比如在交通和制造场景下，数据需要按照时间顺序进行存储，这里的时间不只是一个度量标准，不是一个字段，而是一个坐标的主坐标轴。
这时候，就需要时间序列数据库，有点像我们的常见的股票交易数据，横轴是时间，纵轴是不同时间下的所有数据。
再比如社交网络应用，需要快速查找某人与某人的关系。
此时如果使用图数据库，可以快速 get 到结果，但是用关系型数据库，需要大量的查询时间，甚至超时。
总之，应用千差万别，数据丰富多彩，要想应用跑的爽，就要投其所好，选最合适的数据库。
而且如今，大多数现代应用，都不是单一类型数据库来支撑，往往众人拾柴，各干自己擅长的一部分。
所以，对于架构师来说，根据自家业务，把数据库选好、规划好很重要，同时，还要有 DBA 来配置和管理数据库。
想想就很头大！
有没有供应商，能够提供一揽子解决方案呢？还真有，那就是 Amazon Web Services (AWS) ，上面提到的 8 种类别的数据库，AWS 全部提供！
AWS 能提供的数据库类型和引擎太多，我们就挑几类来讲讲吧。
首先还是说关系型数据库，虽然数据库分类这么多，但站 C 位的还是“关系”，大多数系统的主数据都还是用关系型数据库。
AWS 的托管式 Amazon Relational Database Service (Amazon RDS) 服务，提供了多种引擎。
不管开发者习惯用哪种，商用的 Oracle、SQL Server，开源的 MySQL、MariaDB、PostgreSQL，在 AWS 上都能找到。
同时，AWS 还提供了一套自家特色 RDS 方案，这就是著名的「极光」数据库——Amazon Aurora。
Amazon Aurora 提供 MySQL 和 PG 两种兼容引擎，跨 3 个 AZ 最多提供 15 个读副本、6 份数据拷贝，跨区横向扩展读写，跨区复制。
“极光普照”之下，吞吐量是 MySQL 的 5 倍、PG 的 3 倍，成本却只有传统商业级数据库的十分之一。
看到“3AZ”，是不是担心部署和管理很复杂？没关系，Amazon Aurora 是全托管的，所有操作，云上帮你全简化。
同时，Amazon Aurora 跟 AWS 上的机器学习、BI、分析类的组件可以深度集成，你甚至不需要专业的机器学习知识，用标准的 SQL 语句就能进行机器学习预测了。
著名的虎牙直播，就采用了 Amazon Aurora 数据库解决方案，相对静态的信息，使用 Amazon Aurora 存储，动态的信息则使用 Amazon DynamoDB 存储。
除了性能比 MySQL 好太多以外，故障恢复也是极速的，异常状态下，10s 内就能自动实现故障转移，终端用户无感知。
另外，虎牙直播的 Nimo TV 是出海业务，利用 AWS 全球数据库功能，可以就近部署，提升用户本地体验。
我们再来说说 AWS 上的其它非关系型数据库吧。
当下最流行的缓存数据库是 Redis 和 Memcached，AWS 提供 Amazon ElastiCache，兼容这两种引擎，为实时应用提供亚毫秒延迟。
如果谈到文档数据库，大家肯定会对 MongoDB 很熟悉，AWS 的 Amazon DocumentDB 提供对 MongoDB 的兼容能力。
不止于兼容，Amazon DocumentDB 比标准的 MongoDB 托管服务快两倍，支持自动故障转移，并在 3 个 AZ 上提供 6 份数据副本。
AWS 上的图数据库托管服务叫做 Amazon Neptune，可存储数十亿的“关系”，查询起来，延迟是毫秒级别的。
Amazon Neptune 被广泛应用于社交网络、知识图谱、生命科学、IT 运维等领域。
还有宽表数据库 Amazon Keyspaces，分类账数据库 Amazon QLDB，以及刚刚上新的时序数据库 Amazon Timestream……
总之，只有想不到的，没有 AWS 做不到的。
讲到这里，我想大家对 AWS 云上数据库服务的类型和能力，大概都心中有数了。
这两年，我也看到越来越多本地部署的数据库，被云上数据库替代和“碾压”。
那么，如果你也有了数据库上云的想法，如何才能方便、安全、快捷地把本地数据“搬”上云呢？
AWS 提供了一系列 DMS 服务：从线下到云上、从库到库、库结构转换……，数据复制可实现近乎 0 停机时间，以保障业务不中断，客户无感知。
这种迁移服务靠谱不？Amazon 自己就是最好的成功案例。
亚马逊公司 100 多个业务团队，各种复杂的、在线的、高并发的业务，电商、广告、视频、游戏、支付，原来总共使用了 7500 多个甲骨文数据库，数据多达 75 PB。
如今，这些数据库全部被迁移、分流到 AWS 多种云数据库上了。
自己家的云数据库到底香不香？迁移后数据库成本降低 60%，管理工作减少了 70%，而对于重要的应用，性能提高 40%！
这就是活生生的云数据库最佳实践呀！
云上数据库库库库库库库库，八仙过海。AWS，就是那片云海！
