NewSQL 与传统优化/分片 [关闭]

Posted 2023-02-16

【中文标题】NewSQL 与传统优化/分片 [关闭]

【英文标题】：NewSQL versus traditional optimization/sharding [closed]

【发布时间】：2012-05-18 14:41:02

【问题描述】：

我们是一家小型初创公司，拥有大量写入的 SAAS 应用程序，并且（终于！）达到了我们的使用量出现扩展问题的地步。我们有一个小团队，因此我们非常感谢能够将系统管理员卸载到 Heroku 和 RDS。

虽然 Heroku（大部分）没问题，但 RDS 存在一些问题：

缩放。这是最大的担忧。我们目前运行一个 XL RDS 实例。通过简单的优化，我们将能够度过一段时间，但除非我们对应用程序进行一些重大的结构更改，否则我们将在某个时候遇到瓶颈。

此外，更改实例大小的停机时间也很糟糕。

可用性。我们运行一个多可用区实例，因此我们应该在单个可用区中断中幸存下来。但是RDS是建立在EBS之上的，考虑到EBS的历史和设计，这让我很担心。

价格。我们的 RDS 账单是我们支付 Heroku 的 4 倍。我不介意付钱给亚马逊，以免我雇用系统管理员，但我很想找到更便宜的东西。

在我看来，我们有两个前进的选择：传统方法（分片、运行夜间作业以将我们的部分数据库移动到只读状态等）；或 NewSQL 解决方案（Xeround、VoltDB、NimbusDB 等）。

传统专业人士：以前已经做过很多次了，而且有相当标准的方法来做。

传统的缺点：这将需要大量的工作，并且会给应用程序带来很大的复杂性。它也不会解决 RDS 的次要问题（可用性和价格）。

NewSQL 专家：假设这些解决方案将在不更改应用程序代码的情况下横向扩展我们的数据库（受 SQL 功能的一些限制，例如不使用悲观锁定）。这将为我们节省大量的工作。它还将提高可靠性（无单点故障）并降低成本（不必在非工作时间运行 XL 实例以提供高峰使用）。

NewSQL 缺点：这些解决方案相对较新，我还没有找到任何关于人们在生产应用程序中使用它们的经验的好的评论或文章。我只找到了一个可用作托管解决方案 (Xeround)，所以除非我们使用那个，否则我们必须在系统管理员中投入资源。

我想知道对于我的最佳选择是什么意见。

Xeround 非常诱人（托管 NewSQL），但我无法找到在生产中使用它的任何好的信息。我看到的几条推文都是人们抱怨它有点慢。我很紧张要转向似乎未经测试的东西。

我保守的一面说要坚持使用 RDS 并使用传统方法。但就开发人员的时间而言，这将是非常昂贵的。

然后我的一部分想知道是否有另一种方法，也许是我从未听说过的更久经考验的托管 NewSQL 解决方案。或者可能是我们必须自己托管的 NewSQL 解决方案，但它的历史非常可靠。

提前感谢您的想法。

【参考方案1】：

不确定您是否听说过 NuoDB。但它是一个全新的 SQL 解决方案，提供了 NoSQL 的横向扩展能力和传统 OLTP 的 SQL & ACID 合规能力。你应该看看解决方案。

【参考方案2】：

在 Jingit (www.jingit.com)，我们对 VoltDB 进行了实战测试。在扩展编写繁重的应用程序和 AWS 云方面非常棒。没有托管选项，因此我们的开发人员拥有它，他们每周花费不到 1 小时来管理我们的 VoltDB 集群。我们实际上同时使用 RDS 和 VoltDB。 RDS 用于我们的传统关系工作负载，而 VoltDB 用于我们的 HIGH VOLUME 事务处理。如果您使用 Java 进行开发，那么 VoltDB 非常适合您使用 Java 编写所有程序。

【参考方案3】：

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