我认为我可以使用 SimpleDB 来处理我的应用程序中最具挑战性的领域（就缩放而言） - 类似 twitter 的评论，但位置在顶部 - 直到我坐下来真正开始实施它深发展。
首先，SDB 每个属性值有 1000 字节的限制，即使是注释也不够（可能需要将较长的值分解为多个属性）。
然后，最大域大小为 10GB。承诺是您可以扩展而不必担心数据库分片等，因为 SDB 不会随着数据负载的增加而降级。但是，如果我理解正确，对于域，我将遇到与分片完全相同的问题，即。在某些时候需要在应用程序级别实现跨域的数据记录分布和查询。
即使对于我在整个应用程序中拥有的最简单的对象，即。原子用户评级，SDB 不是一个选项，因为它无法计算查询中的平均值（一切都是基于字符串的）。因此，要计算对象的平均用户评分，我必须加载所有记录——一次 250 条——并在应用程序级别进行计算。
我错过了关于 SDB 的一些东西吗？10GB 的数据库真的可以克服所有 SDB 限制吗？老实说，我非常热衷于利用 SDB，因为我已经使用了 S3 和 EC2，但现在我根本看不到用例。
我在几个大型应用程序上使用 SDB。每个域 10 GB 的限制确实让我担心，但我们在亚马逊上赌博，如果我们需要它允许扩展它。如果您想要更多空间，他们会在他们的网站上提供申请表。
至于跨域连接，不要将 SDB 视为传统数据库。在将数据迁移到 SDB 期间，我不得不对其中的一些数据进行非规范化处理，以便手动进行跨域连接。
每个属性 1000 字节的限制也很难解决。我拥有的一个应用程序是一个博客服务，它在数据库中存储帖子和评论。在将它移植到 SDB 时，我遇到了这个限制。我最终将帖子和评论作为文件存储在 S3 中，并在我的代码中阅读。由于此服务器位于 EC2 上，因此到 S3 的流量不会花费任何额外费用。
也许需要注意的其他问题之一是 SDB 上的最终一致性模型。您不能写入数据然后再将其读回，并保证新写入的数据将返回给您。最终数据将被更新。
说了这么多，我还是喜欢深发展。我不后悔改用它。我从 SQL 2005 服务器移出。我认为我对 SQL 有更多的控制权，但是一旦放弃了这种控制权，我就有了更多的灵活性。不需要预先定义模式很棒。在您的代码中使用强大而健壮的缓存层，很容易使 SDB 更加灵活。
我在 SimpleDB 中有大约 50GB，跨 30 个域进行分片。我使用它来允许存储在 S3 中的对象上的多个键，并降低我的 S3 成本。我没有尝试过使用 SimpleDB 进行全文搜索，但我不会尝试。
SimpleDB 可以工作，很简单，等等，但它并不是适合所有情况的一组功能。在您的情况下，如果您需要聚合，SimpleDB 不是正确的解决方案。它是围绕数据库只是一个键值存储的学派构建的，聚合应该由一个聚合过程来处理，该过程将结果写回键值存储。这正是某些应用程序所需要的。
值得补充的是，虽然必须跨域编写自己的分片逻辑并不理想，但在性能方面。例如，如果您需要搜索 100gb 的数据，最好让 20 台每台 5gb 的机器对它们负责的部分执行相同的搜索，而不是一台机器必须执行整个任务。如果您的目标是最终得到一个排序列表，您可以从 20 个同时查询返回的最佳结果，并在发起请求的机器上对它们进行整理。
也就是说，如果您想获得较低级别的内容，我宁愿看到它从正常使用中抽象出来，并且在 API 中有类似“提示”的东西。因此，如果您碰巧存储了 100gb 的数据，让 Amazon 决定是跨 20 台机器还是 10 台或 40 台机器进行分区，然后分配工作。例如，在 Google 的 BigTable 设计中，随着表的增长，它会不断划分为 400mb 的平板电脑。从表中请求一行就这么简单，BigTable 的工作就是找出它在一个或数百万个平板电脑中的位置。
再说一次，BigTable 要求您编写 MapReduce 调用来执行查询，而 SimpleDB 会为您动态索引自身，因此您赢了一些，也输了一些。
如果每个属性的存储大小是问题，您可以使用 S3 存储更大的数据，并将链接存储到 SDB 中的 s3 对象。S3 不仅适用于文件，它还是一种通用的存储解决方案。
亚马逊试图让你实现一个简单的对象数据库。这主要是出于速度原因。将 SimpleDB 记录视为 S3 中元素的指针/键。通过这种方式，您可以运行查询（针对 SimpleDB 慢速获取结果列表，或者当您需要一次检索或修改记录时，您可以使用键（快速）直接点击 S3 来拉取对象。
这些限制似乎适用于当前的Beta版本。我认为在他们弄清楚如何能够经济地满足需求之后，他们将在未来允许更大的数据库。即使有限制，支持高可扩展性和可靠性的 10GB 数据库也是一种有用且具有成本效益的资源。
请注意，可扩展性是指在数据量或请求量增长的同时保持稳定而浅的性能曲线的能力。这并不一定意味着最佳性能，也不意味着非常高容量的数据存储。
Amazon SimpleDB 还提供免费服务层，因此您可以存储多达 1GB，每月传输多达 1GB，使用长达 25 小时的机器时间。虽然这个限制听起来很低，但它是免费的这一事实允许一些小规模的客户使用该技术，而无需投资大型服务器场。
我正在构建一个商业 .NET 应用程序，它将使用 SimpleDB 作为其主要数据存储。我还没有投入生产，但我也一直在构建一个开源库，它解决了使用 SimpleDB 与 RDBS 的一些问题。我的路线图上的一些功能与您提到的问题有关：
SimpleDB 仍在积极开发中，最终肯定会拥有许多今天没有的功能（一些添加到核心系统中，一些添加到代码库中）。
.NET 库是Simple Savant。
我不买关于 SimpleDB 的所有炒作，基于以下限制，我看不出应该使用它的原因（我知道现在你可以用几乎任何技术构建几乎任何东西，但这不是选择一个的理由） .
所以我看到的限制：
如果这还不够，那么您还必须忘记基本的东西，如group by,以及数据操作。总的来说，查询语言非常初级，只是提醒了 SQL 可以做什么的一小部分。sum averagedistinct
所以功能并不比 Redis/Memcached 更丰富，但我非常怀疑它在用例中的性能是否与这两个数据库一样好。
SimpleDB 将自己定位为无模式的基于文档的 nosql 数据库，但 MongoDB/CounchDB 的查询语法更具表现力，它们的局限性也更加合理。
最后，不要忘记供应商锁定。如果在几年内 Azure（或其他可能出现的东西）将提供比 AWS 便宜 5 倍的云托管，那真的很难转换。
SimpleDB .. 的重点不是用作所有数据的数据库，而是用作其他非传统“DB”数据存储（例如 S3）中数据的索引。这就是我将 SimpleDB 用于 ETL 流程之类的事情的方式。我的 S3 数据湖中的数据必须被索引，但 S3 没有合适的索引，这是 SimpleDB 的最佳用例之一（恕我直言）
谷歌这个：“simpledb s3 索引”
请注意，它不必专门针对 S3。您可能在 EFS / EBS 甚至 SES 中有您想要索引的数据。SimpleDB 是一个很好的解决方案，可以为几乎任何东西提供简单的快速索引。我发现 DynamoDB 在为您所需的吞吐量及其与成本的关系方面的配置方面过度杀伤和不必要地过于复杂，并且听说过与此相关的恐怖故事。使用 SimpleDB，性能始终如一，成本可预测。
阅读：https ://segment.com/blog/the-million-dollar-eng-problem/
鉴于这一事实以及任何复杂的事情，还有其他用于数据存储/索引的解决方案，例如 Sphinx、Postgres、Mongo ..等，我的问题一直是当其他解决方案同样快时，DynamoDB 成本陷阱的意义何在但是，不需要吞吐量配置，并且具有可预测的成本。DynamoDB 是 AWS 抢钱（恕我直言）。他们不能逐步淘汰 SimpleDB，因为有太多现有的已知客户依赖它。AWS 本身也依赖它。如果它真的像他们声称的那样被 DynamoDB 取代，那么每个人都会转移到 Dynamo，这不会是一个讨论。