SimpleDB、OpenID 和云能走多远？

Question

我正在开发一个 ASP.NET MVC 应用程序（非事务型、社交型）。我开始使用 .NET 授权提供程序来完成这项工作，但随着云的衬里变得越来越闪亮，我想知道我可以推升多少。

最终，我希望废除 ISP 托管的 SQL Server 数据库，并随着内容的增加逐步开始使用 S3。

我正在考虑使用 OpenID 进行身份验证，使用 SimpleDB 来存储用户详细信息。如果我理解正确的话，用户添加的任何内容都可以在 ClaimedIdentifier 上键入。

这样做的优点/缺点是什么？这种方法的亮点是什么？

有没有人有任何纯云架构的例子可以用来支持支持/反对的论点？

Answer 1

我认为使用 OpenID 的好处是众所周知的。使用 SimpleDB 存储用户详细信息的优点包括：

• 灵活的模式允许您直接支持某些类型的动态用户数据，而使用 RDBMS 可能会很麻烦。例如，用户定义的配置文件字段，或任意长的列表（如果值如电子邮件地址）。数据可以直接存储，不需要另一个表来连接。
• 您没有需要调整的设置和配置选项，因此很简单。您基本上将服务器维护和数据库维护任务外包。如果您继续使用托管 SQLServer 解决方案，那么您也在做这件事，但程度较轻。我不了解共享 SQLServer 托管，但在性能一致性和可用性问题方面，我对共享 MySQL 托管有过不好的经历。
• 这是 SimpleDB 声称的另一件事：所有数据自动跨数据中心复制，并且集群中的所有服务器能够独立处理读取和写入，从而实现更好的可用性。如果整个数据中心变黑或者路由器真的融化了，您的应用程序可能仍然会嗡嗡作响。也许服务水平会下降，但如果规划得当，功能齐全。当问题得到解决后，数据会自动在后台同步备份。
• 良好的表现。它的速度不如本地托管的无负载 SQLServer 实例那么快，但开箱即用，它对于用户数据（及更多数据）来说足够快，并且可扩展性良好。
• 如果您在 Amazon EC2 Windows 服务器上运行 ASP.NET 应用程序，则可以在服务器和 SimpleDB 之间实现快速、免费的数据传输。典型的往返 ping 时间在 2 毫秒到 7 毫秒之间。
• 免费使用套餐涵盖每月 1GB 带宽、1GB 存储和 25 小时盒子使用量。根据应用程序的不同，您可能可以免费走很远的路。

缺点包括：

• 没有关系、约束或模式，因此您必须在一定程度上进行非规范化。您想要检查的约束必须在代码中完成，并且您想要执行的连接将需要后续查询来模拟。与后续查询和主键的连接并不像听起来那么糟糕，因为 SimpleDB 具有可靠的查询 API 并针对并发请求进行了优化。很多时候，即使是复杂的连接也可以在 SimpleDB 的 2 次往返（相当于时间）中进行模拟。
• 您没有可以调整的设置和配置选项。
• 您必须能够处理最终一致性。您始终可以在项目级别应用原子更新和删除，但在正常操作期间更新可能不会显示在读取请求中一整秒（根据我的经验，不能保证）。当然，在发生故障的情况下，时间会更长。 “处理它”通常必须在会话级别进行。如果用户更新了她的个人资料（使用您的应用程序）并且其他人在几秒钟内都看不到更改，那没关系，但如果她的视图在几秒钟内恢复到旧状态，那就糟糕了。有一些简单的方法可以解决这个问题，但是您必须考虑这些问题并解决它们。
• 你受亚马逊的摆布。不会有什么不好的事情发生，而且并不一定比受 SQLServer 托管公司的摆布更糟糕。但这可能会引起一些人的担忧。比 SQLServer 情况更糟糕：如果您与 Amazon 分手，SimpleDB 应用程序将无法在其他任何地方运行（本地运行的 M/DB 实例除外）。