亚马逊SimpleDB

Question

有没有人考虑过使用类似亚马逊SimpleDB数据存储的东西作为后端数据库？

SQL Server托管(至少在英国)是昂贵的，所以像这样的东西和云文件存储(S3)可以用来构建可以随应用程序一起增长的应用程序吗？

理论上很棒，但有人会考虑使用它吗？事实上，现在有没有人在真正的生产软件中使用它，因为我很乐意阅读您的评论。

Answer 1

这是Dare对亚马逊服务的一个很好的分析。

我通常听人说S3处理的是"blob存储“。典型的Web应用程序通常具有媒体文件和其他资源(图像、CSS样式表、脚本、视频文件等)，它们只需通过名称/路径进行访问。然而，这些资源中的许多也有元数据(例如，YouTube上的视频文件有关于它的评级、上传它的人、浏览量等的元数据)，这些元数据也需要存储。这种对可查询、系统化存储的需求就是SimpleDB的用武之地。EC2提供了一个可用于计算的虚拟服务器，其中包含一个本地文件系统实例，如果虚拟服务器因任何原因停机，该实例都不会持久。有了SimpleDB和S3，当您加上EC2提供的计算功能时，您就拥有了构建大型“Web2.0”风格应用程序的构建块。然而，对于那些仅仅想要典型的LAMP或SimpleDB开发人员构建数据库驱动的Web应用程序的开发人员，或者那些可能具有不能很好地适应blob存储或系统化存储的自定义存储需求的应用程序的开发人员，S3和SimpleDB都没有提供解决方案。如果不能访问持久文件系统，亚马逊云计算平台上的开发人员必须想出复杂的解决方案，包括手动将数据从EC2备份到S3，以获得所需的体验。

Answer 2

我刚刚完成了一个库的编写，以便在Perl中轻松地将应用程序移植到simpledb，Net:: Amazon ::SimpleDB::Simple，因为我发现Amazon客户端库很痛苦。这个库还不在CPAN上，但它在http://rjurneyopen.s3.amazonaws.com/SimpleDB/Simple.pm上的想法是让进出SimpleDB的散列变得微不足道。

我只是移植了一个应用程序来使用它。总的来说，我对SimpleDB印象深刻……即使是低效的查询也只需要2-3秒就能返回。由于SimpleDB的Erlang/并行特性，它似乎并不关心表的大小。Tablescans对它来说很简单。

痛苦来自于你不能计数、求和或分组的事实。如果你打算做任何一件事...那么SimpleDB可能不适合你。目前，就功能而言，它存在于memcached和MySQL之间。您可以选择按限制排序，这很好用。这也很好，你不必自己扩展它，它也很好，因为它不关心你在其中投入了多少。但更高级的操作，如分析，充其量也是痛苦的。你将不得不做你自己的计算服务器端。这也是一个很大的优势，在任何计算机上，我都可以使用simpledb CLI http://code.google.com/p/amazon-simpledb-cli/来查询我的数据。

有一些令人困惑的“问题”。例如，属性可以有多个值，并且在存储项时必须显式设置“replace”。另外，存储undef或null字符串会导致库错误，而不是删除属性名称/值对或将其设置为空/空字符串。

学习以一种很大程度上非规范化的方式思考也有点奇怪，这就是为什么我会赞同上面的建议，即它最适合于新的应用程序。从SQL应用程序移植到SimpleDB将是痛苦的，因为您的应用程序逻辑必须更改。你做事情的方式有点不同。亚马逊的文档很好地解释了这一点。

所有这些都可以在位于SimpleDB之上的库中提取，所以为了使用SimpleDB，您需要选择一个好的库……您可能不想直接处理它。在PHP端有一些工作可以让事情变得简单，这就是我的库。有一个RAILS激活源，但它似乎对您没有太大帮助。

总而言之，它还处于早期阶段，但与其他API (想到了twitter)相比，我不得不说SimpleDB REST API非常简单(特别是考虑到它是XML语言)并且易于使用。我推荐它..。这取决于您的应用程序的需求和您使用它的经济性。如果您希望快速扩展一个不会给DB带来很大负载的服务，并且不想为可扩展的MySQL/memcache组合而烦恼……然后，SimpleDB可以为您提供一个“简单”的解决方案。

我预计它的功能将继续增长，对于越来越多做更复杂和有趣事情的应用程序来说，它将是一个很好的选择。但现在，它的目标是典型的Web2.0服务，并且适用于该服务。

Answer 3

我们几乎只在我们的新项目中使用SimpleDB。零维护、高可用性、无需安装的特性实在太好了。对于你的Ruby开发人员，可以看看SimpleRecord，这是一个类似ActiveRecord的SimpleDB界面，它非常容易使用。