Amazon RDS介绍 （三）

     前面两个章节，对Amazon RDS介绍的也差不多了，我想大家应该都比较了解了。当然，我想有些朋友可能想知道 RDS的使用步骤以及一些定价策略，这个，我只能说，去Amazon RDS官网，它提供了详细的操作文档，肯定比我描述的要好，呵呵！ 这一章，我主要站在我的角度上，列出几个我认为RDS存在的缺点，欢迎各位指正以及分析更多RDS的问题，当然，如果这些问题已经有解决方法了，请大家告知，不胜感激.

 

RDS存在的问题

 

   其实，在最近的项目实施过程中，我们使用了 Amazon的RDS， 根据RDS的官方描述，我认为RDS目前还是存在一些问题的，希望RDS以后能有所改进吧。 我认为主要的问题有：

   服务的封装性太强: 其实这个特点，有些人看来也许不算缺点吧 ，毕竟封装是为了让用户使用起来更加方便，不需要用户来操作或自己配置一些底层细节吧。 但是，在有些时候，它还是会产生一些问题的。 首先，大家要明白，RDS是运行在Amazon EC2(相当于虚拟机）上的，可是，我们无法知道这个EC2的详细信息，更服务采用SSH登录进入该EC2了，所以，一些操作我们没法处理，如我想在这个运行RDS的EC2上，查看某些耗时SQL的执行计划，目前是不能的；还有你也不能在该EC2上安装一些监控分析工具。

    同时，RDS备份产生的备份文件、事务日志文件以及你手动创建的 snapshot(快照）都是存储在Amazon 的 S3上的，但是我们也无法得到存放这些数据的S3 bucket的所有信息，从而也无法得到这些数据。

      备份文件问题： 如前所描述，你放在Amazon RDS上的数据，如果使用RDS的备份机制，就只能在 Amazon云平台上还原，无法拿到本地来进行保留还原。 如果数据很重要，且假如Amazon 破产了（虽然几率渺茫），这些数据怎么办？

      监控分析问题： 是的，Amazon RDS给你提供了一些监控数据，但是我认为这些数据时非常简单的，监控的粒度也是非常粗的，仅仅是些CUP、内存、存储、当前连接数量等一些信息，假如，我要知道系统里，哪些SQL很耗时，耗时多长，想知道SQL的执行计划，怎么办？目前没法做.

     运维升级问题： 目前，你要是使用RDS时，必须制定一个 Amazon RDS 运维维护时间段，一周一般为4个小时，这4个小时，Amazon会给你的RDS做一些维护操作，如版本升级，数据备份等。 这是个要命的4个小时，因为在这个时间段，你的数据是不能用的，和当机4个小时没什么差别。（这个地方，有木有什么好的处理方式，我在研究，到时更新，各位别急啊）

    扩展问题： RDS目前好像没提供方便的横向扩展功能, 虽然提供了可读副本作为横向扩展，但是RDS的负载均衡做得怎么样？我就不清楚了，但有一点现在可以确定， 面对数据的写 非常频繁时，RDS还没有提供解决方案.