键值存储与 RDBM 与“云”数据库 (SDB) [关闭]

Question

过去几年我设计了多个应用程序，然后不断改进性能和可扩展性方面，我对 MySQL 领域感到很自在。我也有一些使用 memcached 为经常查询的结果集提供应用程序端加速的经验。最近，我将 Amazon SDB 作为我的主要“数据库”用于电子商务实验。

为了过于简单化，我想到使用 SDB 服务的一个快速理由是，使用无模式数据库结构可以让我专注于我的项目的逻辑问题并在我的数据存储中快速积累内容.也就是说，不必担心事先设置和规范化产品属性的所有可能排列；只需开始加载产品，SDB 就会记住所有可用的内容。

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

现在我正在阅读诸如 Tokyo Cabinet 之类的项目，这些项目正在扩展内存中键值存储的概念，以快得离谱的速度提供伪关系功能（我在某处读到 14 倍）。

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

例如：在原型设计阶段，应用程序的逻辑/技术未知数使数据结构变得流畅：使用 SDB。 在优先考虑用户可交付成果的成熟阶段，使用传统工具，您不必花费开发时间编写排序、分组或分页逻辑。

非常感谢您使用这些工具的实际经验。

谢谢！

沙希布河

Answer 1

您发现的问题是为什么 RDBMS 专家对某些替代系统持怀疑态度。是的，替代系统处理某些特定要求的速度非常快，但是一旦您想用相同的数据做其他事情，最快速的系统就会突然变得落后。相比之下，RDBMS 通常会更加沉着地管理变化。对于 Fleetest 经过微优化以处理的专门工作负载，它可能不如 Fleetest 快，但在被要求处理其他查询时它很少会恶化。

Answer 2

新的解决方案不是灵丹妙药。

与传统的 RDBMS 相比，这些系统通过权衡其他方面（降低的查询能力、最终一致性、某些操作的糟糕性能）在某些方面（可扩展性、可用性或简单性）进行了改进。

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

以 Amazon Simple DB 为例，SDB 基本上是一个巨大的电子表格，如果您的数据是这样的，那么它可能运行良好，并且出色的可扩展性和简单性将为您节省大量时间和金钱。

如果您的系统需要非常结构化和复杂的查询，但您坚持使用其中一种很酷的新解决方案，那么您很快就会发现自己正处于重新实现一个业余的、设计不良的 RDBMS 的过程中，它的所有固有的问题。

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

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

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