使用Amazon SimpleDB有什么意义?

我认为我可以使用SimpleDB来处理我的应用程序中最具挑战性的领域(就扩展而言) – 类似twitter的评论,但位置在最前面 – 直到我坐下来实际开始实施SDB。

首先,SDB每个属性值有1000个字节的限制,即使对于注释来说也是不够的(可能需要将更长的值分解为多个属性)。

那么,最大的域大小是10GB。 这个承诺是可以扩展而不用担心数据库分片等问题,因为SDB不会随着数据量的增加而降低。 但是,如果我理解正确的话,我将有与分区完全相同的问题,即。 在某些时候需要实现数据logging在应用程序级跨域的分发和查询。

即使是我在整个应用程序中最简单的对象, primefaces用户评级,SDB不是一个选项,因为它不能计算查询内的平均值(一切都是基于string的)。 因此,要计算某个对象的平均用户评分,我将不得不加载所有logging(每次250个),并在应用程序级别上进行计算。

我错过了关于SDB的一些事情吗? 10GB真的是一个数据库,以克服所有的SDB限制? 因为我已经使用了S3和EC2,所以我对使用SDB充满了热情,但现在我只是没有看到一个用例。

我在几个大型应用程序上使用SDB。 每个域名的10GB限制令我担心,但是我们在亚马逊上赌博,如果我们需要的话可以扩展。 如果你想要更多的空间,他们在他们的网站上有一个请求表格。

就跨域join而言,不要把SDB看作传统的数据库。 在将数据迁移到SDB的过程中,我必须对其进行非规范化处理,以便手动执行跨域连接。

每个属性限制1000字节也很难解决。 我有一个应用程序是一个博客服务,在数据库中存储post和评论。 在将它移植到SDB时,我遇到了这个限制。 我最终在S3中将文章和评论存储为文件,并在我的代码中读取。 由于该服务器位于EC2上,因此到S3的stream量不需要额外的费用。

也许还有一个需要注意的问题是SDB的最终一致性模型。 您不能写入数据,然后再读取它,并保证新写入的数据将被返回给您。 最终数据将被更新。

所有这一切都说,我还是喜欢深圳发展银行。 我不后悔切换到它。 我从一个SQL 2005服务器移动。 我想我对SQL有更多的控制,但是一旦放弃了这个控制,我就拥有了更多的灵活性。 不需要预先定义模式是非常棒的。 在代码中有一个强大而健壮的caching层,可以使SDB更加灵活。

我在SimpleDB中有大约50GB,分成30个域。 我使用它来允许在S3中存储对象上的多个键,也可以降低我的S3成本。 我还没有使用SimpleDB进行全文search,但我不会尝试。

SimpleDB的工作原理很简单,但是对于每种情况来说都不是一套正确的function。 在你的情况下,如果你需要聚合,SimpleDB不是正确的解决scheme。 它是build立在学校思想的基础上的,数据库只是一个关键的价值存储,聚合应该通过将结果写回关键值存储的聚合过程来处理。 这正是一些应用程序所需要的。

这里是我如何使用SimpleDB捏一分钱的描述

值得补充的是,尽pipe跨领域编写自己的分片逻辑并不理想,但是在性能方面。 例如,如果您需要search100GB的数据,最好让20台机器每台持有5GB的数据在他们负责的部分执行相同的search,而不是一台机器执行整个任务。 如果您的目标是结束sorting列表,您可以从20个同步查询中返回最佳结果,并在启动请求的计算机上对它们进行核对。

也就是说,我希望看到这个从正常使用中抽象出来,并且如果你想要更低层次的话,在API中有一些“提示”。 所以,如果你碰巧存储了100GB的数据,让亚马逊决定是否跨20台机器或10或40分区,并分配工作。 例如,在Google的BigTabledevise中,随着表格的增长,它不断地被分成400mb的平板电脑。 从表格中寻找一行就像这样简单,BigTable做的工作就是确定一台平板电脑或者数百万台平板电脑的位置。

再次,BigTable要求你编写MapReduce调用来执行一个查询,而SimpleDB为你dynamic地索引自己,所以你赢了一些,你输了一些。

如果每个属性的存储大小是问题,则可以使用S3来存储更大的数据,并将链接存储在SDB中的s3对象中。 S3不仅仅是文件,它是一个通用的存储解决scheme。

亚马逊正试图让你实现一个简单的对象数据库。 这主要是出于速度的原因。 将SimpleDBlogging看作S3中元素的指针/键。 通过这种方式,您可以运行查询(对SimpleDB执行缓慢的操作以获取结果列表,或者在需要一次一个地检索或修改logging时,可以直接用键(快速键)键入S3来提取对象。

限制似乎适用于当前的Beta版本。 我猜想,在他们弄清楚如何在经济上为需求提供服务之后,他们会在将来允许更大的数据库。 即使有了这个限制,一个支持高可扩展性和可靠性的10GB数据库也是一个有用且经济高效的资源。

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

Amazon SimpleDB还提供免费服务层 ,因此您可以使用多达25小时的机器时间来存储高达1GB,最高1GB /月的数据。 虽然这个限制听起来很低,但免费的事实允许一些低规模的客户使用这项技术,而不需要投资大的服务器农场。

我正在构build一个商业.NET应用程序,它将使用SimpleDB作为其主数据存储。 我还没有投入生产,但我也一直在构build一个开源库,以解决使用SimpleDB与RDBS有关的一些问题。 我的路线图中的一些function与您提到的问题有关:

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

SimpleDB仍处于积极的发展阶段,最终肯定会有许多今天没有的特性(一些添加到核心系统中,一些添加到代码库中)。

.NET库是简单的专家 。

我不会购买SimpleDB的所有宣传,并基于以下限制无法看到它应该使用的原因(我明白,现在几乎可以用任何技术来构build几乎任何东西,但这不是select其中一个的原因) 。

所以我看到的局限性:

  • 只能在亚马逊AWS上运行,您还应该为一大堆工作人员付款
  • 域(表)的最大大小是10 GB
  • 属性值长度(字段大小)为1024字节
  • select响应中的最大项目 – 2500
  • select的最大响应大小(可以返回的最大数据量) – 1Mb,实际上您可以在此查看所有限制
  • 有几种语言 (java,php,python,ruby,.net)
  • 不允许区分大小写的search。 你必须引入额外的小写字段/应用程序逻辑。
  • sorting只能在一个字段上完成
  • 由于5s的时间限制可以performance出奇怪的 。 如果5秒钟过去了,查询还没有结束,你最终会得到一个部分号码和一个令牌,让你继续查询。 应用程序逻辑负责收集所有这些数据总结。
  • 一切都是一个UTF-8string ,这使得屁股工作与非string值(如数字,date)的痛苦。
  • 对于数字来说,sorting的行为很奇怪(因为一切都是string)。 所以现在你必须做填充萨满舞
  • 都没有交易和join
  • 没有复合,地球静止,多列索引,没有外键

如果这还不够,那么你也不得不忘记基本的东西,如group byaveragedistinct以及数据处理。 在整个查询语言是相当基本的,并提醒了一小部分的SQL可以做。

所以这个function并不比Redis / Memcached更丰富,但是我非常怀疑它的性能和这两个dbs一样好。

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

最后 – 不要忘记供应商locking 。 如果Azure(或其他可能出现的)在几年内提供比AWS便宜5倍的云,那么切换起来确实很难。