我以为我可以使用SimpleDB来处理应用程序中最具挑战性的部分(就扩展而言)-类似Twitter的注释，但将其放在顶部-直到我坐下来开始使用深圳发展银行。
首先，SDB每个属性值有1000个字节的限制，这对于注释来说是不够的(可能需要将较长的值分解为多个属性)。
然后，最大域大小为10GB。 promise 是您可以扩大规模而不必担心数据库分片等问题，因为SDB不会随着数据负载的增加而降级。但是，如果我正确理解的话，对于域，我将遇到与分片(即分片)完全相同的问题。有时需要在应用程序级别跨域实现数据记录的分发和查询。
即使对于我在整个应用程序中拥有的最简单的对象，也就是。原子用户评级，SDB是不可选项，因为它无法计算查询中的平均值(所有内容均基于字符串)。因此，要计算某个对象的平均用户评分，我将不得不加载所有记录-一次250条-并在应用程序级别进行计算。
我是否缺少有关SDB的内容？ 10GB真的可以克服SDB的所有限制吗？我确实对使用SDB充满热情，因为我已经使用过S3和EC2，但是现在我根本看不到用例。
最佳答案
我在几个大型应用程序上使用了SDB。每个域10 GB的限制确实让我担心，但是我们在Amazon赌博，允许我们根据需要扩展它。如果您需要更多空间，他们会在他们的网站上提供请求表。
至于跨域联接，不要将SDB视为传统数据库。在将数据迁移到SDB的过程中，我必须对其中一些数据进行规范化，以便可以手动进行跨域联接。
每个属性限制1000字节也很难解决。我拥有的应用程序之一是博客服务，该博客服务将帖子和评论存储在数据库中。在将其移植到SDB时，遇到了这一限制。我最终将帖子和评论存储为文件在S3中，并在我的代码中阅读了这些内容。由于此服务器位于EC2上，因此到S3的流量不会花费任何额外费用。
可能需要注意的其他问题之一是SDB上的最终一致性模型。您不能写入数据，然后再保证所有新写入的数据都将返回给您，因此不能将其读回。最终，数据将被更新。
综上所述，我仍然爱SDB。我不后悔切换到它。我从SQL 2005服务器迁移。我想我对SQL有更多的控制权，但是一旦放弃该控制权，我就会拥有更大的灵活性。无需预先定义架构就可以了。在代码中具有强大的缓存层，可以轻松使SDB更加灵活。