|
|
1
Mocky
15 年前
我认为使用OpenID的好处是众所周知的。使用simpledb存储用户详细信息的优点包括:
-
灵活的模式允许您直接支持某些类型的动态用户数据,这种方式对于RDBMS来说可能很麻烦。例如,用户定义的配置文件字段,或者任意长的列表(如果值如电子邮件地址)。数据可以直接存储,而不需要另一个表来连接。
-
您没有需要调整的设置和配置选项,所以很简单。您基本上是外包服务器维护和数据库维护任务。如果您继续使用托管的sqlserver解决方案,那么在较小程度上,您也在这样做。我不知道共享的sqlserver托管,但是在性能和可用性问题的一致性方面,我在共享的mysql托管方面有过不好的经验。
-
SimpleDB声称这是另一回事:所有数据都能自动跨数据中心进行复制,并且集群中的所有服务器都能独立处理读写操作,从而提高了可用性。如果整个数据中心都变暗了,或者路由器真的融化了,你的应用程序可能还在嗡嗡作响。也许服务级别降低了,但如果您计划得很好,它就可以完全发挥作用。当问题解决后,数据会自动同步到后台。
-
性能好。它的速度不如本地托管的SQLServer实例快,但开箱即用,对于用户数据(以及更多)来说,它的速度很快,而且扩展性很好。
-
如果您在AmazonEC2Windows服务器上运行ASP.NET应用程序,您可以在服务器和SimpleDB之间快速免费传输数据。典型的往返ping时间介于2 ms和7 ms之间。
-
免费使用层每月覆盖1GB带宽、1GB存储和25小时的机箱使用。根据应用程序的不同,你可能可以免费走很远。
缺点包括:
-
没有关系、约束或模式,因此必须在一定程度上取消规范化。要检查的约束必须在代码中完成,而要执行的联接将需要后续查询来模拟。使用后续查询和主键的联接并没有听起来那么糟糕,因为simpledb有一个可靠的查询API,并且针对并发请求进行了优化。很多时间甚至复杂的连接都可以在simpledb的2次往返中进行模拟。
-
您没有要调整的设置和配置选项。
-
你必须能够处理最终的一致性。您始终可以在项目级别应用原子更新和删除,但在正常操作期间,更新可能在一整秒钟的读取请求中都不会显示(以我的经验,不是保证)。当然,在失败的情况下,时间要长得多。”处理它“通常必须在会话级别进行。如果一个用户更新了她的个人资料(使用你的应用程序),没有人能在几秒钟内看到变化,这是可以的,但如果她的视图恢复到原来的状态几秒钟,那将是不好的。有一些简单的方法可以解决这个问题,但是你必须考虑并解决这些问题。
-
你受亚马逊的摆布。没有什么不好的事情可能发生,也不一定比受SQLServer托管公司的摆布更糟糕。但这可能会引起一些人的关注。比sqlserver更糟的是:如果你和Amazon分道扬镳,simpledb应用程序就不会在其他任何地方工作(除了本地运行的m/db实例)。
|
