4.2 KiB
10.3 关系型数据库（Amazon RDS）
在MySQL基础上，结合Amazon自己的基础设施，Amazon为其云用户开发了改进版的数据库，叫做RDS（Relational Database Service）。尽管论文不怎么讨论RDS，但是论文中的图2基本上是对RDS的描述。RDS是第一次尝试将数据库在多个AZ之间做复制，这样就算整个数据中心挂了，你还是可以从另一个AZ重新获得数据而不丢失任何写操作。
对于RDS来说，有且仅有一个EC2实例作为数据库。这个数据库将它的data page和WAL Log存储在EBS，而不是对应服务器的本地硬盘。当数据库执行了写Log或者写page操作时，这些写请求实际上通过网络发送到了EBS服务器。所有这些服务器都在一个AZ中。
每一次数据库软件执行一个写操作，Amazon会自动的，对数据库无感知的，将写操作拷贝发送到另一个数据中心的AZ中。从论文的图2来看，可以发现这是另一个EC2实例，它的工作就是执行与主数据库相同的操作。所以，AZ2的副数据库会将这些写操作拷贝AZ2对应的EBS服务器。
在RDS的架构中，也就是论文图2中，每一次写操作，例如数据库追加日志或者写磁盘的page，数据除了发送给AZ1的两个EBS副本之外，还需要通过网络发送到位于AZ2的副数据库。副数据库接下来会将数据再发送给AZ2的两个独立的EBS副本。之后，AZ2的副数据库会将写入成功的回复返回给AZ1的主数据库，主数据库看到这个回复之后，才会认为写操作完成了。
RDS这种架构提供了更好的容错性。因为现在在一个其他的AZ中，有了数据库的一份完整的实时的拷贝。这个拷贝可以看到所有最新的写请求。即使AZ1发生火灾都烧掉了，你可以在AZ2的一个新的实例中继续运行数据库，而不丢失任何数据。
学生提问:为什么EBS的两个副本不放在两个数据中心呢？这样就不用RDS也能保证跨数据中心的高可用了。
Robert教授：我不知道怎么回答这个问题。EBS不是这样工作的，我猜是因为，对于大部分的EBS用户，如果每一个写请求都需要跨数据中心传递，这就太慢了。我不太确定具体的实现，但我认为这是他们不这么做的主要原因。RDS可以看成是EBS工作方式的一种补救，所以使用的还是未经更改的EBS工作方式。
如论文中表1所示，RDS的写操作代价极高，就如你所预期的一样高，因为需要写大量的数据。即使如之前的例子，执行类似于 x+10，y-10，这样的操作，虽然看起来就是修改两个整数，每个整数或许只有8字节或者16字节，但是对于data page的读写，极有可能会比10多个字节大得多。因为每一个page会有8k字节，或者16k字节，或者是一些由文件系统或者磁盘块决定的相对较大的数字。这意味着，哪怕是只写入这两个数字，当需要更新data page时，需要向磁盘写入多得多的数据。如果使用本地的磁盘，明显会快得多。
我猜，当他们开始通过网络来传输8k字节的page数据时，他们发现使用了太多的网络容量，所以论文中图2的架构，也就是RDS的架构很明显太慢了。
学生提问：为什么会慢呢？（教室今天好空）
Robert教授：在这个架构中，对于数据库来说是无感知的，每一次数据库调用写操作，更新自己对应的EBS服务器，每一个写操作的拷贝穿过AZ也会写入到另一个AZ中的2个EBS服务器中，另一个AZ会返回确认说写入成功，只有这时，写操作看起来才是完成的。所以这里必须要等待4个服务器更新完成，并且等待数据在链路上传输。
如论文中表1描述的性能所担心的一样，这种Mirrored MySQL比Aurora慢得多的原因是，它通过网络传输了大量的数据。这就是性能低的原因，并且Amazon想要修复这里的问题。所以这种架构增强了容错性，因为我们在一个不同的AZ有了第二个副本拷贝，但是对于性能来说又太糟糕了。