亚马逊SimpleDB

有没有人考虑将Amazon SimpleDB数据存储中的某些东西用作后端数据库？

SQL Server托管(至少在英国是这样)价格昂贵，因此可以将诸如此类的东西与云文件存储(S3)一起用于构建可随您的应用程序增长的应用程序。

理论上很棒，但任何人都会考虑使用它。 实际上，实际上有人愿意将它用于实际的生产软件，因为我很想阅读您的评论。

---

这是对Dare对Amazon服务的很好的分析。

S3处理了我通常所说的" blob存储"。典型的Web应用程序通常具有媒体文件和其他资源(图像，CSS样式表，脚本，视频文件等)，可以通过名称/路径简单地对其进行访问。但是，其中许多资源也具有元数据(例如，YouTube上的视频文件具有有关其分级，上载者，观看次数等的元数据)，也需要存储这些元数据。 SimpleDB可以满足对可查询的，模式化的存储的需求。EC2提供了一个虚拟服务器，该服务器可用于具有本地文件系统实例的完整计算，如果该虚拟服务器由于任何原因停机，该实例将不会持久。使用SimpleDB和S3，当您使用EC2提供的计算功能时，便具有构建大型" Web 2.0"样式应用程序的构造块。
但是，S3和SimpleDB都不为仅希望具有典型LAMP或WISC开发人员经验的开发人员提供构建数据库驱动的Web应用程序的解决方案，也不为那些可能具有定制存储需求而无法完全满足Blob存储或架构化存储。在无法访问持久文件系统的情况下，亚马逊云计算平台上的开发人员不得不想出复杂的解决方案，其中涉及将数据从EC2手动备份到S3以获得所需的体验。

---

我刚刚完成编写一个库，以使将应用程序轻松移植到Perl中的net :: Amazon :: SimpleDB :: Simple的Perl中，因为我发现Amazon客户端库很痛苦。该库尚未在CPAN上使用，但位于http://rjurneyopen.s3.amazonaws.com/SimpleDB/Simple.pm上，其目的是使将哈希值放入和导出SimpleDB变得微不足道。

我只是移植了一个应用程序来使用它。总体而言，SimpleDB给我留下了深刻的印象……即使效率低下的查询也只需2-3秒即可返回。由于它的Erlang / parallel特性，SimpleDB似乎并不在乎表的大小。表格扫描很容易做到。

痛苦来自于这样一个事实，即您无法进行计数，求和或分组。如果您打算做任何事情……那么SimpleDB可能不适合您。就功能而言，目前它存在于memcached和MySQL之间。您可以选择LIMIT ORDER BY LIMIT，这很好。您不必自己缩放它也很不错，也不必关心您在其中塞了多少东西。但是，诸如分析之类的更高级的操作充其量是痛苦的。您将必须自己计算服务器端。另外，在任何计算机上，我都可以使用simpledb CLI http://code.google.com/p/amazon-simpledb-cli/来查询我的数据。

有一些令人困惑的"陷阱"。例如，属性可以具有多个值，并且在存储项目时必须显式设置"替换"。同样，存储undef或null字符串会导致库错误，而不是删除该属性名称/值对或将其设置为null /空字符串。

学会以一种基本上非标准化的方式思考也有些奇怪，这就是为什么我将上面的建议放在第二位的原因，因为该建议最适合新应用。从SQL应用程序移植到SimpleDB会很痛苦，因为您的应用程序逻辑必须更改。您做事的方式有些不同。亚马逊文档非常善于解释这一点。

所有这些都可以从SimpleDB顶部的库中提取出来，因此对于您使用SimpleDB而言，您将需要选择一个好的库...您可能不想直接处理它。在PHP方面有一些使事情变得容易的工作，还有我的库。有一个RAILS活动资源，但似乎对您没有多大帮助。

总而言之，它还处于游戏初期，但是与其他API相比(想到这很麻烦)，我不得不说，SimpleDB REST API非常简单(特别是考虑到它是XML)并且可以使用。我会推荐它...取决于您的应用程序要求和使用它的经济性。如果您希望快速扩展不会给数据库带来很大负担的服务，并且不想为可伸缩的MySQL / memcache组合所困扰，那么SimpleDB可以为您提供一个"简单"的解决方案。

我希望它的功能将继续增长，并且它将成为越来越多的应用程序执行更复杂和有趣的事情的一个不错的选择。但是现在，它针对的是典型的Web 2.0服务并适合您。

---

我们几乎仅将SimpleDB用于新项目。零维护，高可用性，无安装方面都太好了。对于您的Ruby开发人员，请查看SimpleRecord，它是类似于SimpleDB的ActiveRecord的接口，它非常易于使用。

---

SimpleDB非常适合许多应用程序。...如果您的项目需要大量的分析报告，联接等，则可以考虑使用MySQL或混合模型。

如果您使用SimpleDB，我们已经开发了Radquery.com供内部使用，并向公众开放。

---

我没有使用过SimpleDB，但一直在我们的应用程序中使用S3，EC2和MySQL的组合。

只要您愿意使用SimpleDB，那么您不妨考虑使用MySQL(它具有很高的可伸缩性，而且并不昂贵)。

在S3和EC2方面，它在实践中也很棒。

---

但是，您真的需要SQL Server吗？您不能使用PostgreSQL或MySQL吗？事实证明，两者都可以胜任大多数任务。

现在，如果您需要SQL Server功能，那么您就不走运了。

另一种选择是租用服务器。多少钱贵？

(我已经使用Amazon S3来存储应用程序的图像，可以，并且至少可以正常工作)

---