logo标签列表

使用Amazon SimpleDB的目的是什么？

databaseamazon-web-servicesamazon-simpledb
51

我本以为可以使用SimpleDB来处理我的应用程序中（从扩展性角度考虑）最具挑战性的部分 - 带有位置信息的类似Twitter的评论，但直到我坐下来实际开始使用SDB时才发现问题。

首先，SDB每个属性值的限制是1000字节，这甚至对于评论来说都不够，可能需要将较长的值拆分成多个属性。

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

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

我是否忽略了SDB的某些内容？ 10GB真的足以克服所有SDB的限制吗？我最初非常热衷于利用SDB，因为我已经在使用S3和EC2，但现在我简单地看不到用例。

9个回答
35

我在几个较大的应用程序中使用SDB。每个域名的10 GB限制让我有些担心，但我们打赌亚马逊会允许我们扩展它，如果我们需要更多空间，他们在其网站上提供了请求表单。

至于跨域连接，请不要将SDB视为传统数据库。在将我的数据迁移到SDB期间，我不得不对其中一些数据进行去规范化，以便我可以手动进行跨域连接。

每个属性的1000字节限制也很难处理。我有一个博客服务应用程序，它将帖子和评论存储在数据库中。在将其移植到SDB时，我遇到了这个限制。最终我将帖子和评论存储为S3中的文件，并在我的代码中读取它们。由于此服务器在EC2上，因此与S3的通信不会产生额外费用。

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

尽管如此，我仍然喜欢SDB。我没有后悔切换到它。我从SQL 2005服务器迁移而来。我认为我在SQL中有更多的控制权，但一旦放弃了那种控制，我就有了更大的灵活性。不需要预定义模式真是太棒了。通过在代码中使用强大而健壮的缓存层，很容易使SDB变得更加灵活。

4
截至2010年2月24日，SimpleDB可以执行一致性读取和有条件的插入操作。这将使用户能够选择所需的一致性/并发水平。不错！ :) - Kaitsu
12

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

SimpleDB工作正常，易于操作等等，但它并不是每种情况下都具有合适的功能。如果需要聚合功能，则SimpleDB不是正确的解决方案。它是围绕这样一种思路构建的：数据库只是一个键值存储器，并且聚合应该由聚合进程处理，将结果写回到键值存储器中。这恰好是某些应用程序所需的。

这里是一个描述如何使用SimpleDB省钱的方法

7
值得注意的是，虽然在跨域编写自己的分片逻辑并不理想，但从性能方面来看却是有益的。例如，如果您需要搜索100GB的数据，则最好要求持有每个5GB的20台机器在其负责的部分上执行相同的搜索，而不是让一台机器执行整个任务。如果你的目标是得到一个排序列表，你可以从20个同时查询返回的最佳结果中选取，并在发起请求的机器上整理它们。
话虽如此，我更希望将这种抽象化作为正常使用，并像API中的“提示”一样具有更低级别的功能。因此，如果您恰好存储了100GB的数据，请让Amazon决定它是否被分割成20台或10台或40台机器，并分配工作。例如，在Google的BigTable设计中，随着表的增长，它会不断地分割成400MB的平板电脑。从表中请求一行就像这样简单，而BigTable则负责找出它位于一个平板电脑或数百万个平板电脑中的位置。
另一方面，BigTable要求您编写MapReduce调用以执行查询，而SimpleDB会动态地为您索引自身，所以您赢了一些，输了一些。
5
如果每个属性的存储大小是问题所在，您可以使用S3来存储更大的数据，并将指向S3对象的链接存储在SDB中。S3不仅适用于文件，它是一种通用存储解决方案。
5
亚马逊希望您实现一个简单的对象数据库，主要是为了提高速度。将SimpleDB记录视为指向S3元素的指针/键。这样，您可以运行查询（在SimpleDB中较慢）以获取结果列表，或者您可以直接使用键（快速）访问S3，以便在需要一次检索或修改记录时检索或修改对象。
谢谢，我没有意识到与s3链接的重要性。但就个人而言，我仍然看不出任何用例。例如，在评论的情况下，将评论正文存储在外部会使搜索变得不可能，而这是我想做的事情之一。 - Otigo
@Otigo 你需要单独实现搜索/索引器；尽管经典索引似乎是第一步/显而易见的解决方案，但一旦看到结果，你会希望使用像Lucene这样考虑错别字和词干的索引器。换句话说，对于大字段，内置的SimpleDb索引也不会有用。Amazon部分放弃了SimpleDb，因为使用它实现任何东西从来都不简单。 - Chris Moschini
Chris：“SimpleDB被亚马逊抛弃了” - 你是什么意思？ - Jasper
SimpleDB并没有被“放弃”或“废弃”; 我在AWS工作，虽然不在这个服务中，但这不是我们的做法。如果使用量> 0，则该服务将保留，我们可能会删除实例类型或应用程序版本，但API将长期存在。它已经具备了所有功能，大多数人都会说“使用它实现任何东西从来都不简单”，可能也会对DynamoDB有同样的看法，因为后者更难以正确使用。 - LimpingNinja
2
限制似乎适用于当前的Beta版本。我认为在未来他们会允许更大的数据库，但需要找到经济上能够满足需求的方法。即使有这些限制，一个支持高可扩展性和可靠性的10GB数据库是一种有用且具有成本效益的资源。
请注意，可扩展性是指在数据或请求量增加时保持稳定和平缓的性能曲线，并非指最佳性能，也不意味着非常高的容量数据存储。
Amazon SimpleDB还提供免费服务层，因此您可以存储高达1GB的数据，每月传输高达1GB数据，使用高达25小时的机器时间。虽然这个限制听起来很低，但它是免费的，这使得一些小规模的客户可以使用技术，而无需投资大型服务器农场。
1

我不相信SimpleDB周边所有的宣传，并且基于以下限制，我无法看到任何使用它的理由（我知道现在几乎可以使用任何技术构建几乎任何东西，但这并不是选择一种技术的理由）。

那么，我见过的限制有：

  • 只能在亚马逊AWS上运行，您还需要支付一整套的费用。
  • 域（表）的最大大小为10 GB。
  • 属性值长度（字段大小）为1024字节。
  • 选择响应中的最大项目数-2500个。
  • 选择的最大响应大小（可以返回的最大数据量）为1 MB，实际上您可以在此处检查所有限制。
  • 仅支持几种语言的驱动程序（Java、PHP、Python、Ruby、.NET）。
  • 不允许不区分大小写的搜索。您必须引入额外的小写字段/应用程序逻辑。
  • 只能按一个字段进行排序。
  • 由于5秒时间限制，计数可能会表现出奇怪的行为。如果超过5秒而查询尚未完成，则会得到部分数字和一个标记，该标记允许您继续查询。应用程序逻辑负责收集所有这些数据并进行求和。
  • 所有内容都是UTF-8字符串，这使得使用非字符串值（如数字、日期）变得非常麻烦。
  • 数字的排序行为很奇怪（由于所有内容都是字符串）。因此，现在您必须进行带填充的萨满舞蹈。
  • 两者都没有事务和联接。
  • 没有复合、地理静态、多列索引，也没有外键。
如果这还不够，那么您也需要忘记基本的东西，如group by、sum、average、distinct以及数据操作。总体来说，查询语言相当基础，只是 SQL 所能做的小部分子集。
因此，该功能并不比 Redis/Memcached 更为丰富，但我非常怀疑它在它们的用例中表现得像这两个数据库一样好。
SimpleDB 定位为无模式文档型 nosql 数据库，但 MongoDB/CounchDB 的查询语法更加表达力强，它们的限制更加合理。
最后，不要忘记供应商锁定。如果几年后 Azure（或其他出现的东西）提供比 AWS 便宜五倍的云托管，那么很难转换。
1

SimpleDB 的目的是被用作数据存储的索引，而不是所有数据的数据库，尤其是那些非传统的“DB”数据存储，例如 S3。这就是我将 SimpleDB 用于 ETL 过程等事情的原因。我的 S3 数据湖中的数据必须被索引，但 S3 没有合适的索引，这是 SimpleDB 最好的使用案例之一（在我看来）。

搜索关键词：“simpledb s3 index”

请注意，它不一定只针对 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上，这就不会有这样的讨论了。

1

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

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

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

.NET库是Simple Savant。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接