使用 Amazon SimpleDB 有什么意义？答案

【问题标题】：What's the point of using Amazon SimpleDB?使用 Amazon SimpleDB 有什么意义？
【发布时间】：2010-10-13 11:49:45
【问题描述】：

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

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

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

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

我是否缺少有关 SDB 的一些信息？ 10GB 的数据库真的可以克服所有 SDB 限制吗？老实说，我非常热衷于利用 SDB，因为我已经使用了 S3 和 EC2，但现在我根本看不到用例。

【问题讨论】：

标签： database amazon-web-services amazon-simpledb

【解决方案1】：

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

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

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

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

说了这么多，我还是喜欢深发展。我不后悔改用它。我从 SQL 2005 服务器移出。我认为我对 SQL 有更多的控制权，但是一旦放弃了这种控制权，我就有了更多的灵活性。不需要预先定义模式很棒。在您的代码中使用强大而健壮的缓存层，可以轻松使 SDB 更加灵活。

【讨论】：

自 2010 年 2 月 24 日起，可以在 SimpleDB 中执行一致读取和条件放置。这将使用户可以选择所需的一致性/并发级别。好的！ :)

【解决方案2】：

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

SimpleDB 可以工作，很简单，等等，但它并不是适合所有情况的一组功能。在您的情况下，如果您需要聚合，SimpleDB 不是正确的解决方案。它是围绕数据库只是一个键值存储的学派构建的，聚合应该由一个聚合过程来处理，该过程将结果写回键值存储。这正是某些应用程序所需要的。

这里是a description of how I pinch pennies using SimpleDB

【讨论】：

【解决方案3】：

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

也就是说，如果您想获得较低级别的内容，我宁愿看到它从正常使用中抽象出来，并在 API 中提供类似“提示”的东西。因此，如果您碰巧存储了 100gb 的数据，让 Amazon 决定是跨 20 台机器还是 10 台或 40 台机器进行分区，然后分配工作。例如，在 Google 的 BigTable 设计中，随着表的增长，它会不断划分为 400mb 的平板电脑。从表中查询一行就是这么简单，BigTable 会找出它在一个或数百万个平板电脑中的位置。

再说一次，BigTable 要求您编写 MapReduce 调用来执行查询，而 SimpleDB 会为您动态索引自身，因此您赢了一些，也输了一些。

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

【讨论】：

谢谢，我不明白与 s3 链接的重要性。我个人仍然没有看到任何用例。例如，在 cmets 的情况下，将评论正文存储在外部将无法搜索它们，这是我想做的事情之一。
@Otigo 您必须单独实现搜索/索引器；尽管经典索引似乎是第一次通过/显而易见的解决方案，但一旦您看到结果，您就会希望使用像 Lucene 这样的索引器来考虑错别字和词干。换句话说，对于大字段，内置的 SimpleDb 索引无论如何都不会有用。 SimpleDb 被 Amazon 抛弃的部分原因是用它实现任何东西从来都不是简单的。
Chris> “SimpleDB 被亚马逊抛弃了”——你是什么意思？
SimpleDB 没有被“抛弃”或“弃用”；我为 AWS 工作，虽然不是在这项服务中，这不是我们做的事情。如果使用率 > 0，则服务会保留，我们可能会删除实例类型或应用程序版本，但 API 是长期存在的。它功能齐全，大多数人说“用它实现任何东西从来都不是简单的”可能会对 DynamoDB 说同样的话，因为它更难做对

【解决方案6】：

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

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

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

【讨论】：

【解决方案7】：

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

数据的透明分区
伪事务性
属性的透明跨越超过 1000 字节限制

SimpleDB 仍在积极开发中，最终肯定会拥有许多今天没有的功能（一些添加到核心系统中，一些添加到代码库中）。

.NET 库是Simple Savant。

【讨论】：

【解决方案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时间限制count in can behave strange。如果 5 秒过去了，查询还没有完成，你会得到一个部分数字和一个允许你继续查询的令牌。应用程序逻辑负责收集所有这些数据并进行汇总。
everything is a UTF-8 string，这让使用非字符串值（如数字、日期）变得很痛苦。
数字的排序行为很奇怪（因为一切都是字符串）。所以现在你必须做一个shamanic dance with padding
两者都没有事务和连接
无复合、地理静态、多列索引、无外键

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

所以功能并不比 Redis/Memcached 丰富得多，但我非常怀疑它在用例方面的性能是否与这两个数据库一样好。

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

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

【讨论】：

【解决方案9】：

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

谷歌这个：“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 抢钱（恕我直言）。他们不能逐步淘汰 SimpleDB，因为有太多现有的已知客户依赖它。 AWS 本身也依赖它。如果它真的像他们声称的那样被 DynamoDB 取代，那么每个人都会转移到 Dynamo，这不会是一个讨论。

【讨论】：