我认为我可以使用SimpleDB来处理我的应用程序中最具挑战性的区域(就缩放而言) - 类似Twitter的评论,但位置在顶部 - 直到我坐下来实际开始实现它SDB.
首先,SDB每个属性值有1000个字节的限制,即使是注释也是不够的(可能需要将更长的值分解为多个属性).
然后,最大域大小为10GB.承诺是您可以扩展而不必担心数据库分片等,因为SDB不会随着数据量的增加而降级.但是如果我理解正确的话,对于域名,我会遇到与分片完全相同的问题,即.在某些时候需要在应用程序级别跨域实现数据记录的分发和查询.
即使对于我在整个应用程序中使用的最简单的对象,即.原子用户评级,SDB不是一个选项,因为它无法计算查询中的平均值(一切都是基于字符串的).因此,要计算对象的平均用户评级,我必须加载所有记录 - 一次250个 - 并在应用程序级别计算它.
我错过了关于SDB的一些事情吗？10GB真的可以用来克服所有SDB限制吗？我真的很热衷于利用SDB,因为我已经使用了S3和EC2,但现在我根本没有看到用例.
我在几个大型应用程序上使用SDB.每个域名10 GB的限制确实令我担心,但我们正在亚马逊上赌博,如果我们需要,我们可以扩展.如果您想要更多空间,他们会在自己的网站上提供申请表.
就跨域加入而言,不要将SDB视为传统数据库.在将数据迁移到SDB期间,我不得不对其中的一些进行非规范化,以便我可以手动执行跨域连接.
每个属性限制1000字节也难以解决.我有一个应用程序是一个博客服务,它在数据库中存储帖子和评论.在将其移植到SDB时,我遇到了这个限制.我最终将帖子和评论存储为S3中的文件,并在我的代码中读取.由于此服务器位于EC2上,因此流入S3的流量不会增加任何额外成本.
也许需要注意的其他问题之一是SDB上的最终一致性模型.您无法写入数据然后将其读回,并保证新写入的数据将返回给您.最终数据将被更新.
所有这些都说,我仍然喜欢SDB.我不后悔改用它.我从SQL 2005服务器搬了过来.我认为我对SQL有更多的控制权,但是一旦放弃了这种控制,我就会有更大的灵活性.不需要预先定义模式是很棒的.通过代码中强大而强大的缓存层,可以更轻松地使SDB更加灵活.
我在SimpleDB中有大约50GB,分为30个域.我使用它来允许存储在S3中的对象上的多个键,并且还减少了我的S3成本.我没有使用SimpleDB进行全文搜索,但我不会尝试它.
SimpleDB可以工作,很简单,等等,但它并不是适用于所有情况的正确功能集.在您的情况下,如果您需要聚合,SimpleDB不是正确的解决方案.它围绕着思想学派建立,DB只是一个键值存储,聚合应该由聚合过程处理,该过程将结果写回键值存储.这正是某些应用程序所需要的.
这是我如何使用SimpleDB捏便士的描述
值得补充的是,虽然必须跨域编写自己的分片逻辑并不理想,但它在性能方面.例如,如果你需要搜索100gb的数据,最好要求20台机器每个持有5gb来对它们负责的部分执行相同的搜索,而不是一台机器必须执行整个任务.如果您的目标是以排序列表结束,则可以从20个并发查询中返回最佳结果,并在启动请求的计算机上进行整理.
也就是说,我希望看到这是从正常使用中抽象出来的,并且如果你想获得更低级别的话,在API中有类似"提示"的东西.因此,如果您碰巧存储了100GB的数据,让Amazon确定它是分区在20台机器上还是10或40台,并分配工作.例如,在谷歌的BigTable设计中,随着桌面的增长,它不断被划分为400mb的平板电脑.从表中请求一行就这么简单,BigTable负责确定一个平板电脑或其中数百万个平板电脑的位置.
然后,BigTable要求你编写MapReduce调用来执行查询,而SimpleDB为你动态索引,所以你赢了一些,你输了一些.
如果每个属性的存储大小都是问题,则可以使用S3存储更大的数据,并将链接存储到SDB中的s3对象.S3不仅适用于文件,它还是一种通用的存储解决方案.
亚马逊正试图让您实现一个简单的对象数据库.这主要是出于速度原因.将SimpleDB记录视为S3中元素的指针/键.通过这种方式,您可以运行查询(对SimpleDB缓慢获取结果列表,或者您可以使用键(快速)直接命中S3,以便在需要一次一个地检索或修改记录时拉取对象.
京公网安备 11010802040832号 | 京ICP备19059560号-6 