使用Amazon SimpleDB有什么意义？

Question

我认为我可以使用SimpleDB来处理我的应用程序中最具挑战性的区域（就缩放而言） - 类似Twitter的评论，但位置在顶部 - 直到我坐下来实际开始用SDB实现它。

首先，SDB每个属性值有1000个字节的限制，即使是注释也是不够的（可能需要将更长的值分解为多个属性）。

然后，最大域大小为10GB。承诺是您可以扩展而不必担心数据库分片等，因为SDB不会随着数据量的增加而降级。但是如果我理解正确的话，对于域名，我会遇到与分片完全相同的问题，即。在某些时候需要在应用程序级别跨域实现数据记录的分发和查询。

即使对于整个应用程序中最简单的对象，即。原子用户评级，SDB不是一个选项，因为它无法计算查询中的平均值（一切都是基于字符串的）。因此，要计算对象的平均用户评级，我必须加载所有记录 - 一次250个 - 并在应用程序级别计算。

我错过了关于SDB的一些事情吗？ 10GB真的可以用来克服所有SDB限制吗？我真的很热衷于利用SDB，因为我已经使用了S3和EC2，但现在我根本看不到用例。

Answer 1

我在几个大型应用程序上使用SDB。每个域名10 GB的限制确实令我担心，但我们正在亚马逊上赌博，如果我们需要，我们可以扩展。如果您想要更多空间，他们会在自己的网站上提供申请表。

就跨域加入而言，不要将SDB视为传统数据库。在将数据迁移到SDB期间，我不得不对其中的一些进行非规范化，以便我可以手动执行跨域连接。

每个属性限制1000字节也难以解决。我有一个应用程序是一个博客服务，它在数据库中存储帖子和评论。在将其移植到SDB时，我遇到了这个限制。我最终将帖子和评论存储为S3中的文件，并在我的代码中读取。由于此服务器位于EC2上，因此流向S3的流量不会花费任何额外费用。

可能需要注意的其他问题之一是SDB上的最终一致性模型。您无法写入数据然后将其读回，并保证新写入的数据将返回给您。最终数据将被更新。

所有这些都说，我仍然喜欢SDB。我不后悔改用它。我从SQL 2005服务器搬了过来。我认为我对SQL有更多的控制权，但是一旦放弃了这种控制，我就会有更大的灵活性。不需要预先定义模式是很棒的。通过代码中强大而强大的缓存层，可以更轻松地使SDB变得更加灵活。

Answer 2

我在SimpleDB中有大约50GB，分为30个域。我使用它来允许存储在S3中的对象上的多个键，并且还减少了我的S3成本。我没有使用SimpleDB进行全文搜索，但我不会尝试它。

SimpleDB可以工作，很容易，等等，但它并不是适用于所有情况的正确功能集。在您的情况下，如果您需要聚合，SimpleDB不是正确的解决方案。它围绕着思想学派建立，DB只是一个键值存储，聚合应该由聚合过程处理，该过程将结果写回键值存储。这正是某些应用程序所需的。

这是a description of how I pinch pennies using SimpleDB

Answer 3

值得补充的是，虽然必须跨域编写自己的分片逻辑并不理想，但它在性能方面。例如，如果您需要搜索100gb的数据，最好让20台每台机器持有5gb，对其负责的部分执行相同的搜索，而不是一台机器必须执行整个任务。如果您的目标是以排序列表结束，则可以从20个并发查询中返回最佳结果，并在启动请求的计算机上进行整理。

那就是说，我希望看到这是从正常使用中抽象出来的，并且如果你想获得更低级别的话，在API中有类似“提示”的东西。因此，如果您碰巧存储了100GB的数据，让Amazon确定它是分区在20台机器上还是10或40台，并分配工作。例如，在谷歌的BigTable设计中，随着桌面的增长，它不断被划分为400mb的平板电脑。从表中请求一行就这么简单，BigTable负责确定一台平板电脑或数百万台平板电脑的位置。

然后，BigTable要求你编写MapReduce调用来执行查询，而SimpleDB为你动态索引，所以你赢了一些，你就失去了一些。

Answer 4

如果每个属性的存储大小都是问题，您可以使用S3存储更大的数据，并将链接存储到SDB中的s3对象。 S3不仅适用于文件，它还是一种通用的存储解决方案。

Answer 5

亚马逊正试图让您实现一个简单的对象数据库。这主要是出于速度原因。将SimpleDB记录视为S3中元素的指针/键。通过这种方式，您可以运行查询（对SimpleDB来说，获取结果列表的速度很慢，或者您可以使用密钥（快速）直接命中S3，以便在需要一次一个地检索或修改记录时拉出对象。

Answer 6

这些限制似乎适用于当前的 Beta 版本。我认为，在他们弄清楚如何经济地满足需求后，他们将来会允许更大的数据库。即使有这些限制，支持高可扩展性和可靠性的10GB数据库也是一种有用且经济高效的资源。

请注意，可扩展性是指在数据量或请求量增加的同时保持稳定和浅薄的性能曲线的能力。它不一定意味着最佳性能，也不意味着非常高容量的数据存储。

Amazon SimpleDB还提供免费服务层，因此您最多可以存储1GB，最多可以传输1GB /月，最多可以使用25小时的机器时间。虽然这个限制听起来非常低，但它是免费的这一事实允许一些低规模客户使用该技术，而无需投资大型服务器场。

Answer 7

我正在构建一个使用SimpleDB作为其主数据存储的商业.NET应用程序。我还没有投入生产，但我也在构建一个开源库，解决使用SimpleDB和RDBS的一些问题。我的路线图中的一些功能与您提到的问题有关：

• 透明的数据分区
• 伪交易性
• 透明跨越属性 超过1000字节限制

SimpleDB仍在积极开发中，并且最终将拥有它目前没有的许多功能（一些添加到核心系统，一些添加到代码库中）。

.NET库是Simple Savant。

Answer 8

我没有购买围绕SimpleDB的所有炒作，并且基于以下限制无法看到它应该被使用的原因（我明白现在你几乎可以用任何技术构建几乎任何东西，但这不是选择一个。）

所以我看到了限制：

• 只能在亚马逊AWS上运行，您还应该pay for a whole bunch of staff
• 域（表）的最大大小为10 GB
• 属性值长度（字段大小）为1024字节
• 选择回复中的最大项目 - 2500
• Select的最大响应大小（可以返回的最大数据量） - 1Mb，实际上您可以检查所有limitations here
• 只有a few languages的驱动程序（java，php，python，ruby，.net）
• 不允许不区分大小写的搜索。您必须引入额外的小写字段/应用程序逻辑。
• 排序只能on one field
• 因为5s timelimit count in can behave strange。如果5秒过去且查询尚未完成，您最终会得到一个部分号码和一个允许您继续查询的令牌。应用程序逻辑负责收集所有这些数据并进行总结。
• everything is a UTF-8 string，这使得处理非字符串值（如数字，日期）变得很麻烦。
• 排序对数字的行为很奇怪（因为一切都是字符串）。所以现在你必须做shamanic dance with padding
• 两者都没有交易和加入
• 没有化合物，地理位置，多列索引，没有外键

如果这还不够，那么您还必须忘记group by，sum average，distinct等基本内容以及数据操作。整体而言，查询语言非常简陋，并提醒SQL可以做的一小部分。

因此功能并不比Redis / Memcached更丰富，但我非常怀疑它的用例在这两个dbs上的表现一样好。

SimpleDB将自身定位为无架构的基于文档的nosql数据库，但MongoDB / CounchDB的查询语法更具表现力，其局限性更为合理。

最后 - 不要忘记vendor locking。如果在几年内Azure（或其他可能出现的东西）将提供比AWS便宜5倍的云托管，那么切换起来真的很难。

Answer 9

将使用SimpleDB ..的点，而不是将其用作所有数据的数据库，而应将其用作其他非传统“ DB”数据存储（例如S3）中数据的索引。这就是我将SimpleDB用于ETL流程之类的方式。我的S3数据湖中的数据必须建立索引，但是S3没有合适的索引，这是SimpleDB（IMHO）的最好的用例之一

Google this：“ simpledb s3索引”

注意，它不一定专门用于S3。您可能在EFS / EBS甚至是您要索引的SES中都有数据。 SimpleDB是提供几乎所有内容的简单快速索引的绝佳解决方案。我发现DynamoDB在为您的所需吞吐量进行配置以及它与成本的关系方面过大，不必要地过于复杂，并且听到了与此有关的恐怖故事。使用SimpleDB，性能始终如一，成本可预测。

请阅读：https://segment.com/blog/the-million-dollar-eng-problem/

鉴于这一事实以及任何复杂的问题，还有其他用于数据存储/索引的解决方案，例如Sphinx，Postgres，Mongo ..etc，我的问题一直是，当其他解决方案被采用时，DynamoDB成本陷阱的意义何在？速度一样快，但是，它不需要进行配置，并且具有可预测的成本。 DynamoDB是一个AWS资金获取（IMHO）。他们无法淘汰SimpleDB，因为知道它的现有客户太多了。 AWS本身也依赖它。如果他们声称DynamoDB确实取代了DynamoDB，那么每个人都将转移到Dynamo，这不是讨论。