NewSQL与传统优化/分片

Question

我们是一个小型创业公司,拥有一个写得很重的SAAS应用程序,并且(最终!)达到我们的使用呈现扩展问题的程度.我们有一个小团队,所以我们非常感谢能够将系统管理员卸载到Heroku和RDS.

虽然Heroku(大部分)都很好,但我们在使用RDS时遇到了一些问题:

1. 缩放.这是最大的担忧.我们目前运行XL RDS实例.我们可以通过简单的优化获得更长的时间,但除非我们对我们的应用程序进行一些重大的结构更改,否则我们将在某个时刻遇到瓶颈.

此外,更改实例大小的停机时间很糟糕.

1. 可用性.我们运行多个AZ实例,因此我们应该在单个AZ中断后继续存在.但是RDS是建立在EBS之上的,这让我非常担心EBS的历史和设计.

2. 价钱.我们的RDS账单是我们支付Heroku的4倍.我不介意付钱亚马逊让我免于雇用系统管理员,但我很想找到更便宜的东西.

在我看来,我们有两个选择:传统的方法(分片,运行夜间工作以将我们数据库的部分移动到只读状态等); 或者是NewSQL解决方案(Xeround,VoltDB,NimbusDB等).

传统专业人士:之前已经做了很多次,并且有非常标准的方法可以做到这一点.

传统缺点:这将需要大量工作并在应用程序中引入显着的复杂性.它也无法解决RDS(可用性和价格)的次要问题.

NewSQL专业人士:据推测,这些解决方案将在不改变应用程序代码的情况下水平扩展我们的数据库(受SQL限制的一些限制,如不使用悲观锁定).这将为我们节省大量的工作.它还可以提高可靠性(无单点故障)并降低成本(无需在非工作时间运行XL实例以提供高峰使用率).

NewSQL缺点:这些解决方案相对年轻,我无法在生产应用程序中找到任何好的评论或人们对它们的体验.我只发现一个可用作托管解决方案(Xeround),所以除非我们使用那个,否则我们必须在sysadmin中投入资源.

我想知道我最好的选择是什么意见.

Xeround非常诱人(托管NewSQL),但我无法在生产中找到任何有用的信息.我见过的几条推文都让人抱怨它有点慢.我很担心搬到看似未经测试的东西.

我保守的一面是坚持使用RDS并采用传统方法.但就开发时间而言,这将是非常昂贵的.

然后我的一部分想知道是否还有另一种方式,也许是一个经过实战考验的托管NewSQL解决方案,我还没有听说过.或者也许是一个NewSQL解决方案,我们必须自己托管,但这有着非常可靠的历史.

提前感谢您的想法.

Answer 1

在 Jingit (www.jingit.com)，我们拥有经过实战考验的 VoltDB。它在扩展写入量大的应用程序和 AWS 云中非常棒。没有托管选项，因此我们的开发人员拥有它，他们每周花费不到 1 小时来管理我们的 VoltDB 集群。我们实际上同时使用 RDS 和 VoltDB。RDS 用于我们的传统关系工作负载，VoltDB 用于我们的大容量事务处理。如果您使用 Java 进行开发，VoltDB 非常适合您，因为您用 Java 编写所有过程。