在谈这家丧心病狂的公司之前，先说说“正常”的IT公司是怎样的：
一家IT公司，一般只会有一款数据库产品。
我们众所周知的Oracle,Microsoft(SQL),MongoDB等等都是这样。
（像Oracle买了拥有MySQL的Sun这样的，不能算了，毕竟MySQL不是Oracle最开始自主研发的。）
为什么会这样呢？原因主要有2个：
1.如果一家公司，能有一款拿得出手的数据库产品，就可以在整个IT业界立足了，实在没有必要开发第二款数据库。
2.数据库系统的开发成本也比较高，投入很大，很少有公司有能力去开发多款数据库。
所以，反过来说，如果一家IT公司，它开发了很多款不同类型的数据库，那它一定有2个特质：
1.有野心：一款数据库，不足以实现它独霸整个DBaaS（数据库即服务）的野心，所以它要开发6款；
2.有钱：数据库的开发不像软件开发，人才很少，重金买人，才能开发数据库。
看来，“丧心病狂”也不是那么容易的！
今天我们要讲的这家“丧心病狂”的开发了6款数据库产品的公司就是亚马逊（Amazon），确切地说是亚马逊的云计算部门，也就是AWS。
AWS有哪6款数据库呢？
确切地说，我认为是7款数据库：
*RDS
*RDS-Aurora
*Redshift
*DynamoDB
*Neptune
*Timestream
*QLDB
(RDS和RDS-Aurora有些人认为是同款数据库。)
这几款数据库真是各有神通，几乎把所有数据库相关的应用场景都捕捉到了。
接下来逐一介绍下：
RDS（RelationalDatabaseService)
RDS顾名思义就是“关系型数据库”。这里其实亚马逊移植了市面上常用的几款数据库，做成了“云”的版本给客户，包括：Oracle，MySQL,MSSQL,MariaDB,PostgreSQL。
这么做的好处，就是客户教育成本低，迁移成本低，用自己熟悉的数据库，又享受了云端的高可用和高性能。
这些好像没啥，很“正常”，还不够“丧心病狂”，但是接下来的几款数据库产品，AWS就要开挂了。
RDS-Aurora
虽然说，Aurora是挂在RDS下面的一个数据库产品，但是我认为它完全是不一样的。不能和其它RDS数据库相提并论。
数据库的一个核心问题就是解决“高并发”，其中包括：高并发的“读”，和高并发的“写”。（比如一个电商平台的网站，对商品的查询都是读，下订单则都是写了。）
你可能会说，高并发的“读”不难处理啊！可多几个数据部分不就行了？比如，一份数据放在10个服务器上--对于读，来说，是这样的。
但是，如果系统里面有很多数据副本的时候，高并发的“写”就不能有效的同步到所有的副本上了--所以，高并发的读写实际上是一对儿矛盾的综合体。
Aurora通过“日志即数据”的概念，把“数据引擎”和“数据存储”进行了有效的分割，从而达到了空前的高并发读写机能。
传统的普通数据库服务，或者普通的自建数据库机构，“写”只能发生在一个“主”数据上，然后“主”再把自己的数据同步给其它副本。Aurora则不同，“写”可以发生在任何一个可用区上。Aurora的架构使用了3个可用区，每个可用区有2个副本，也就是一共6个副本，这6个副本都可以进行读写。极大的弥补了，传统数据库对高并发的瓶颈。这是不是很“丧心病狂”？这是如何做到的？！
细节，在这里就不赘述了，有兴趣的话，可以咨询我们的架构师~
高并发的读写是典型的OLTP（On-LineTransactionProcessing联机事务处理过程）中发生的场景。那么对于OLAP（On-LineAnalyticalProcessing在线分析过程），AWS提出了什么产品呢？
Redshift
和OLTP场景下，数据库需要支持高并发读写不同，OLAP场景下数据库读写频率很低，数据库需要进行大量的聚合计算：数据量大，计算量也大。（比如，一天结束之后，我们需要对今天的用户行为进行分析，所有用户行为数据可能是几个TB。）
这时候，就需要Redshift出场了。Redshift说起来也是关系型数据库，但是它和RDS们有个本质的不同，它不是按“行”来存储数据的，而是按“列”来的。不仅如此，它还按照“列”，对数据进行了排序！基本上这就是为了做“聚合”而诞生的数据库啊！而且按列聚合的数据库很方便压缩，Redshift可以处理PB级数据哦！！！
你说这就可以了吧：传统的关系型数据库，AWS有了；OLTP数据库有了；OLAP数据库也有了。AWS觉得还不够！
DynamoDB
上面的都是关系型数据库。DynamoDB是AWS提供的一款“非关系型数据库”，特别以“键值存储”为核心。可以高效的进行大数据/大文件的快速读取。
如果你是游戏行业/医疗行业/影视娱乐行业有大文件需要读取的话，那么你有福了。：）
Neptune
关系型数据库有了，非关系型也有了！还不够吗？对于亚马逊来说，当然不够！
AWS又推出了“图数据库”。在现在这个社交应用（大数据相关性）横行的年代，没有图数据库，取一个简单的人际关系，用“关系型数据库”真是要累死的。举2个简单的例子：
1.我们想知道用户A和用户B是几度好友？如果A和B是直接好友也就罢了，用关系型数据库Join一次也就行了。但是，万一是10度好友呢？总不能Join10次吧。关键是，如果不知道是几度好友，难道要无限的Join下去吗？
2.我们的物流系统报告，北京到上海的一趟货车延迟了，那有多少用户会受到影响呢？一趟车可能影响10条物流链路？影响50个城市?影响个用户？估计我们需要把系统里面所有的数据都关联查询一遍才能有个结论，成本太高了。
在上面的场景里面（也就是不断的大量的Join出现的时候），图数据库就是一个利器了。
这都已经好几款数据库了，还不够吗？AWS觉得还不够。年的时候，它居然同时发布了两款新数据库！！！
我真是要给这家公司跪了。
Timestream
顾名思义，Timestream是和时间相关的数据库。因为很多对数据的查新都是以时间段为基础的。Timestream就是针对这个场景的。
QLDB
QLDB的全称是QuantumLedgerDatabase。它的应用场景也很好理解，最适合的场景是“记账本”。“账本”是不能被更改的，每一笔记录都不能被改动，被忠实的记录下来，已被查询。QLDB就应运而生了。是不是有点儿“区块链”的意思？只不过QLDB是有中心的。
说了这么多~，说到底，AWS的“丧心病狂”，源自于它“对客户的痴迷”，亚马逊绞尽脑汁，把所有用户能提出的业务场景都想到了，无论我们有什么业务需求都可以用某款数据库解决。