在过去几年中设计了多个应用程序的MySQL空间我感到很自在，然后不断改进性能和可伸缩性方面。我也有一些使用memcached的经验，可以在经常查询的结果集上提供应用程序端加速。最近我将Amazon SDB作为我电子商务实验的主要“数据库”实施。
为了过度简化，我在使用SDB服务时想到的一个快速理由是使用无模式数据库结构可以让我专注于我的项目的逻辑问题并快速在我的数据存储中累积内容。也就是说，不要担心事先设置和规范产品属性的所有可能排列;只需开始加载产品，SDB就会记住所有可用的东西。
既然我已经设法完成了项目的前几次迭代，并且我需要为数据设置简单的接口，那么我正在运行我已经习惯使用MySQL的问题。例如：在select语句中进行分组并限制语法以查询“items 50到100”。我使用SDB的无架构体系结构获得的轻松优势，使用仅超过1800个项目查询/循环结果集而失去了性能。
现在我正在阅读像Tokyo Cabinet这样的项目，这些项目正在扩展内存中键值存储的概念，以极其快的速度提供伪关系功能（14x我在某处阅读）。
我的问题： 我作为应用程序设计人员/开发人员可以通过哪些基本准则或启发式方法来评估哪个数据库技术最适合我项目的每个阶段。
Ex：在原型设计阶段，应用程序的逻辑/技术未知数使数据结构变得流畅：使用SDB。 在用户可交付成果优先的更成熟的阶段，使用传统工具，您不必花时间编写排序，分组或分页逻辑。
非常感谢使用这些工具的实际经验。
非常感谢！
Shaheeb R.
答案 0 :(得分：5)
您遇到的问题是RDBMS专家为什么会看到一些带有黄疸眼睛的替代系统。是的，替代系统可以非常快速地处理某些特定要求，但是一旦你想用相同的数据做其他事情，最快就会变得落后。相比之下，RDBMS通常以更大的沉着来管理变化;它可能不会像最狡猾的微型优化处理的专业工作负载那样快，但在被要求处理其他查询时很少会恶化。
答案 1 :(得分：4)
新的解决方案不是银子弹。
与传统的RDBMS相比，这些系统通过权衡取消其他方面（缩减查询能力，最终一致性，某些操作的可怕性能）在某些方面（可扩展性，可用性或简单性）进行了改进。
认为这些不是传统数据库的替代品，但它们是满足已知特定需求的专用工具。
以Amazon Simple DB为例，SDB基本上是一个巨大的电子表格，如果这就是您的数据，那么它可能运行良好，卓越的可扩展性和简单性将为您节省大量的时间和金钱。
如果你的系统需要非常结构化和复杂的查询，但你坚持使用这些很酷的新解决方案之一，你很快就会发现自己处于重新实现一个业余的，设计不良的RDBMS的过程中固有的问题。
在这方面，如果您不知道这些是否符合您的需求，我认为在传统的RDBMS中进行前几次迭代实际上更好，因为它们为您提供了最佳的灵活性和功能，尤其是在单个服务器部署中并在适度的负荷下。 （见CAP Theorem）。
一旦您对数据的外观以及使用方式有了更好的了解，就可以将您的需求与替代解决方案相匹配。
如果您想要云托管解决方案的简单性，但需要关系数据库，则可以查看：Amazon Relational Database Service