我们目前正准备将一个流量相当大的网站迁移到云端。
我们正在考虑使用 scalr 来帮助我们管理整个设置，特别是因为我们没有使用亚马逊的经验。
我们不确定是否应该使用依赖于 EBS 支持的 EC2 实例的 Scalr MySQL 功能，或者是否应该使用 RDS 甚至 xeround 并享受更轻松的维护和管理。
我们的数据集约为 40GB，应用程序服务器和数据库服务器之间每月消耗 4000 GB 的带宽。
有类似设置的经验吗？
提前致谢
答案1
我可以根据我对大型数据库的经验告诉你...但比你的数据库大得多，大约 90gigs。
我们使用了 RDS，每天至少有 3-4 次查询延迟非常严重。例如，原本需要一秒钟的查询会持续 10-20 秒。我们转移到了他们最大的实例，该实例由突袭 EBS 支持，性能大致相同，但我们没有遇到那些非常严重的延迟峰值。
答案2
迁移到云确实是一个非常好的选择 - 扩展云应用程序最困难的部分是扩展数据库。不要混淆，MySQL 有故障转移解决方案（需要多长时间……），可以支持多个副本来处理读取。如果您知道限制是什么，Scalr 和 RDS 是非常相关的选项……使用 Scalr – 它们将通过配置数据库从属、主服务器和配置数据复制来扩展您的数据库。虽然自动配置确实很方便，复制确实提供了一些补救措施，但请记住，添加读取复制不会修复 OLTP 写入……，也不会处理真正的按需线性弹性。每次添加读取副本时，它都可能是服务事件。
对于 HA，Scalr 使用 EBS。如果上一次 AWS EBS 非常长的停机时间有任何迹象……，请确保您的数据/存储也是 HA……
可扩展解决方案需要线性且具有弹性（横向扩展、缩小、向上、向下），并且能够按需进行，且不会出现任何停机时间。云应用程序需要真正的本机 HA – 多个副本始终执行读写操作，而不是故障转移。RDS 将证明相同的“预配置 MySQL”设置，因此具有相同的限制。最后但并非最不重要的是，确保没有单点故障，并且每次更改应用程序时都会对开发人员产生影响……。在 Xeround，我们的设计目标是解决这些问题。我们的电信级基因和解决方案从第一天开始就作为云操作的虚拟开发，使我们能够提供按需、弹性、超级可扩展且高度可用的“无忧”云数据库。
我们已经运行了一年的测试版，有数千名用户，其中许多与您完全一样。
我们现在是 GA - 请登录30 次免费试用（无需信用卡）并亲自检查一下。
拉齐·沙里尔（Xeround）。