键值存储与RDBMs对比“云”数据库(SDB)

Question

在过去的几年里，我在MySQL领域设计了几个应用程序，然后不断地改进性能和可伸缩性。我也有一些使用memcached的经验，可以在频繁查询的结果集上提供应用程序端的加速。最近，我实现了亚马逊SDB作为我的电子商务实验的主要“数据库”。

为了过于简单，我在脑海中快速地考虑了使用SDB服务的理由，即使用无模式的数据库结构将允许我专注于项目的逻辑问题，并在我的数据存储中快速积累内容。也就是说，不必担心预先设置和标准化产品属性的所有可能排列；只需开始加载产品，SDB就会简单地记住所有可用的内容。

现在，我已经成功地完成了项目的前几次迭代，并且需要为数据设置简单的接口，现在我要解决我在使用MySQL时认为理所当然的问题。例如:在select语句中分组，并将语法限制为查询"items 50 to 100“。我使用SDB的无模式架构获得的易用性优势是，我输给了查询/循环包含1800个项目的结果集的性能损失。

现在，我读到了一些项目，比如东京橱柜，它们正在扩展内存中键值存储的概念，以便以快得离谱的速度提供伪关系功能(我在某些地方读到了14倍)。

我的问题是:作为一名应用程序设计人员/开发人员，我是否可以通过一些基本的指导原则或启发式方法来评估在项目的每个阶段哪种DB技术是最合适的。

例如:在应用程序的逻辑/技术未知使数据结构流动的原型阶段:使用SDB。在更成熟的阶段，优先考虑用户可交付内容，使用传统工具，这样您就不必花费开发时间编写排序、分组或分页逻辑。

如果您有使用这些工具的实际经验，我们将非常感谢。

谢谢，所以！

Shaheeb R.

Answer 1

新的解决方案不是银弹。

与传统的关系数据库系统相比，这些系统在某些方面(可伸缩性、可用性或简单性)通过对其他方面(查询能力降低、最终的一致性、某些操作的糟糕性能)进行了权衡。

请不要将它们视为传统数据库的替代品，而是针对已知的特定需求的专用工具。

以Amazon Simple DB为例，SDB基本上是一个巨大的电子表格，如果您的数据看起来就是这样，那么它可能工作得很好，卓越的可扩展性和简单性将为您节省大量时间和金钱。

如果您的系统需要非常结构化和复杂的查询，但您坚持使用这些很酷的新解决方案之一，您很快就会发现自己正在重新实现一个业余的、设计糟糕的关系型数据库管理系统，以及它的所有固有问题。

在这方面，如果您不知道这些是否适合您的需要，我认为在传统的RDBMS中进行最初的几次迭代实际上更好，因为它们为您提供了最好的灵活性和功能，特别是在单个服务器部署和适度负载下。(参见CAP Theorem)。

一旦您对数据的外观和使用方式有了更好的了解，您就可以使用替代解决方案来满足您的需求。

如果您想要云托管解决方案的简单性，但又需要关系数据库，您可以查看：Amazon Relational Database Service

Answer 2

您所发现的问题就是为什么RDBMS专家以黄疸的眼光看待一些替代系统的原因。是的，替代系统处理某些特定需求的速度非常快，但只要您想用相同的数据做其他事情，最快的就会突然变得落后。相比之下，RDBMS通常以更从容的方式管理变化；对于专门的工作负载，RDBMS的速度可能不如对最快的工作负载进行微优化处理的最快的工作负载快，但当被调用处理其他查询时，RDBMS的性能很少恶化。