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

还不确定您是否听说过NuoDB。但它是一个全新的SQL解决方案，提供NoSQL的扩展功能以及SQL＆amp;传统OLTP的ACID合规性能力。你应该看看解决方案。

Answer 2

在Jingit（www.jingit.com），我们对VoltDB进行了战斗测试。它非常适合扩展写入大量应用程序和AWS云。没有托管选项，所以我们的开发者拥有它并且他们花费＆lt;每周1小时管理我们的VoltDB集群。我们实际上同时使用RDS和VoltDB。我们传统的关系工作负载的RDS，以及我们的HIGH VOLUME事务处理的VoltDB。如果您使用Java进行开发，那么当您使用Java编写所有过程时，VoltDB非常适合。

Answer 3

我也听说NuoDB很有意思。我听到的一件事是，Rackspace很快就会推出云端DBaaS。我不知道他们会使用什么样的味道，但你可以看到Nuo如何作为一个可扩展的解决方案与他们一起工作。我认为它将与Open Stack平台一起运行，当它们打开它时，可能会更加成本和计算效率。只是我自己一直在关注的事情。