有没有人考虑过使用类似于 Amazon SimpleDB 数据存储的东西作为他们的后端数据库？
SQL Server 托管（至少在英国）很昂贵，因此可以将这样的东西与云文件存储 (S3) 一起用于构建可以随应用程序增长的应用程序。
理论上很好，但有人会考虑使用它。事实上，现在有没有人真正将它用于真正的生产软件，因为我很想阅读您的评论。
john
问问题
7004 次
6 回答
14
这是Dare对亚马逊服务的一个很好的分析。
S3 处理了我通常听到的被称为“blob 存储”的内容。一个典型的 Web 应用程序通常具有媒体文件和其他资源（图像、CSS 样式表、脚本、视频文件等），它们可以通过名称/路径简单地访问。然而，很多这些资源也有需要存储的元数据（例如，YouTube 上的视频文件有关于其评级、上传者、观看次数等的元数据）。这种对可查询、模式化存储的需求正是 SimpleDB 的用武之地。EC2 提供了一个虚拟服务器，可用于完成计算，并带有一个本地文件系统实例，如果虚拟服务器因任何原因出现故障，该实例不是持久的。使用 SimpleDB 和 S3，您可以构建大型“Web 2.0”类 当您投入 EC2 提供的计算能力时，您可以创建风格的应用程序。然而，S3 和 SimpleDB 都没有为只需要典型 LAMP 或 WISC 开发人员构建数据库驱动的 Web 应用程序的开发人员提供解决方案，或者为可能具有不适合 blob 存储桶的自定义存储需求的应用程序提供解决方案或模式化存储。在无法访问持久文件系统的情况下，亚马逊云计算平台上的开发人员不得不提出复杂的解决方案，包括手动将数据从 EC2 备份到 S3 以获得所需的体验。然而，S3 和 SimpleDB 都没有为只需要典型 LAMP 或 WISC 开发人员构建数据库驱动的 Web 应用程序的开发人员提供解决方案，或者为可能具有不适合 blob 存储桶的自定义存储需求的应用程序提供解决方案或模式化存储。在无法访问持久文件系统的情况下，亚马逊云计算平台上的开发人员不得不提出复杂的解决方案，包括手动将数据从 EC2 备份到 S3 以获得所需的体验。然而，S3 和 SimpleDB 都没有为只需要典型 LAMP 或 WISC 开发人员构建数据库驱动的 Web 应用程序的开发人员提供解决方案，或者为可能具有不适合 blob 存储桶的自定义存储需求的应用程序提供解决方案或模式化存储。在无法访问持久文件系统的情况下，亚马逊云计算平台上的开发人员不得不提出复杂的解决方案，包括手动将数据从 EC2 备份到 S3 以获得所需的体验。
于 2008-09-10T13:15:03.310 回答
11
我刚刚写完一个库，以便在 Perl 中轻松地将应用程序移植到 simpledb，Net::Amazon::SimpleDB::Simple，因为我发现 Amazon 客户端库很痛苦。该库尚未在 CPAN 上，但位于http://rjurneyopen.s3.amazonaws.com/SimpleDB/Simple.pm 其想法是让在 SimpleDB 中输入和输出哈希变得简单。
我刚刚移植了一个应用程序来使用它。总的来说，SimpleDB 给我留下了深刻的印象……即使是低效的查询也只需 2-3 秒即可返回。由于其 Erlang/并行性质，SimpleDB 似乎并不关心表的大小。表扫描很容易。
痛苦来自于你无法计算、求和或分组的事实。如果您打算做任何这些事情……那么 SimpleDB 可能不适合您。目前就功能而言，它介于 memcached 和 MySQL 之间。您可以按限制选择订单，这很好。您不必自己扩展它也很好，而且它不在乎您往里面塞了多少东西也很好。但更高级的操作（如分析）充其量是痛苦的。您必须在服务器端进行自己的计算。在任何计算机上我都可以使用 simpledb CLI http://code.google.com/p/amazon-simpledb-cli/来查询我的数据，这也是一大优势。
有一些令人困惑的“陷阱”。例如，属性可以有多个值，并且您必须在存储项目时显式设置“替换”。此外，存储 undef 或 null 字符串会导致库错误，而不是删除该属性名称/值对或将其设置为 null/空字符串。
学习以很大程度上未标准化的方式思考也有点奇怪，这就是为什么我会支持上面的建议，即它最适合新应用程序。从 SQL 应用程序移植到 SimpleDB 会很痛苦，因为您的应用程序逻辑必须改变。你做事的方式有点不同。亚马逊文档非常擅长解释这一点。
所有这些都可以在位于 SimpleDB 之上的库中提取，因此对于您使用 SimpleDB，您将需要选择一个好的库……您可能不想直接处理它。PHP 方面有一些工作可以让事情变得简单，还有我的库。有一个 RAILS activesource，但它似乎对你没有多大作用。
总而言之，它仍处于游戏初期，但与其他 API（想到 Twitter）相比，我不得不说 SimpleDB REST API 非常简单（特别是考虑到它是 XML）并且使用起来很有礼貌。我会推荐它...取决于您的应用程序的要求和您使用它的经济性。如果您希望快速扩展一项不会给数据库带来很大负载的服务，并且不想为可扩展的 MySQL/memcache 组合而烦恼……那么 SimpleDB 可以为您提供“简单”的解决方案。
我预计它的功能将继续增长，它将成为越来越多执行更复杂和有趣事情的应用程序的不错选择。但现在它针对并适合您的典型 Web 2.0 服务。
于 2008-12-31T23:16:33.490 回答
3
我们几乎只将 SimpleDB 用于我们的新项目。零维护、高可用性、无安装方面太好了。对于您的 Ruby 开发人员，请查看SimpleRecord，这是一个类似于 ActiveRecord 的 SimpleDB 接口，它非常易于使用。
于 2010-02-06T01:21:09.397 回答
0
但是你真的需要 SQL Server 吗？你不能使用 PostgreSQL 或 MySQL 吗？事实证明，两者都适用于大多数任务。
现在，如果您需要 SQL Server 功能，那么您就不走运了。
另一种选择是租用服务器。贵到什么程度？
（我已经使用 Amazon S3 来存储应用程序的图像，这没关系，并且工作正常，至少在这方面）
于 2008-09-10T09:29:02.840 回答
0
我没有使用过 SimpleDB，但我们的应用程序一直在使用 S3、EC2 和 MySQL 的组合。
只要你愿意使用 SimpleDB，那么你不妨考虑使用 MySQL（它的扩展性很强，而且价格也不贵）。
在 S3 和 EC2 方面，它在实践中也很棒。
于 2008-09-10T09:32:02.083 回答
0
SimpleDB 适用于许多应用程序......如果您的项目需要大量分析报告、加入等，您可以考虑使用 MySQL 或混合模型。
如果您使用 SimpleDB，我们开发了 Radquery.com 供我们内部使用，并向公众开放。
于 2010-11-16T09:15:08.057 回答