我真的很想使用 SimpleDB，但我担心如果没有真正的锁定和事务，整个系统会存在致命缺陷。我知道对于高读/低写的应用程序来说这是有道理的，因为最终系统会变得一致，但是介于两者之间的时间呢？似乎在不一致的数据库中正确的查询会以一种很难追踪的方式在整个数据库中造成破坏。希望我只是一个担心的疣......
【问题讨论】：
标签： sql database amazon-web-services amazon-simpledb
这是一致性和可扩展性以及 - 在某种程度上 - 可用性之间的经典之战。有些数据并不总是需要如此一致。例如，查看 digg.com 和一个故事的挖掘次数。很有可能值在“digg”记录中重复，而不是强制数据库对“user_digg”表进行连接。如果这个数字不完全准确，这有关系吗？可能不是。然后使用像 SimpleDB 这样的东西可能是一个不错的选择。然而，如果你正在编写一个银行系统，你可能应该把一致性放在首位。 :)
除非您从第一天开始就知道必须处理大规模，否则我会坚持使用更简单的传统系统，例如 RDBMS。如果您在具有合理商业模式的地方工作，那么如果流量激增，您有望看到收入大幅增长。然后你可以用这笔钱来帮助解决扩展问题。扩展很难，扩展也很难预测。大多数伤害你的扩展问题都是你意想不到的。
我宁愿建立一个网站，并在流量增加时花几周时间解决规模问题，然后再花很多时间担心规模问题，以至于我们因为资金用完而永远无法投入生产。 :)
【讨论】：
假设你在谈论this SimpleDB，你不是在担心；有真正的理由不将其用作真实世界的 DBMS。
您从 DBMS 中的事务支持获得的属性可以缩写为“A.C.I.D.”：原子性、一致性、隔离性和持久性。 A和D主要与系统崩溃有关，而C和我则与常规操作有关。在使用商业数据库时，这些都是人们完全认为理所当然的事情，因此，如果您使用的数据库没有一个或多个，那么您可能会遇到许多令人讨厌的意外。
原子性：任何事务要么完全完成，要么根本不完成（即，它要么完全提交要么中止）。这适用于单个语句（如“UPDATE table ...”）以及更长、更复杂的事务。如果您没有这个，那么任何出现问题（例如，磁盘已满，计算机崩溃等）都可能会导致半途而废。换句话说，您永远不能依赖 DBMS 来真正完成您告诉它的事情，因为任何数量的现实世界问题都可能成为阻碍，甚至一个简单的 UPDATE 语句也可能会部分完成。
一致性：您为数据库设置的任何规则都将始终得到执行。就像，如果你有一条规则说 A 总是等于 B，那么任何人对数据库系统所做的任何事情都不能破坏该规则——任何尝试的操作都会失败。如果您的所有代码都是完美的，这并不那么重要......但真的，什么时候会出现这种情况？另外，如果您错过了这个安全网，那么当您输掉比赛时，事情会变得非常糟糕......
隔离：对数据库执行的任何操作都将像连续发生（一次一个）一样执行，即使实际上它们是同时发生的（彼此交错）。如果不止一个用户同时访问这个数据库，而你没有这个，那么你做梦也想不到的事情就会出错；即使是原子语句也可以以不可预见的方式相互交互并搞砸。
耐用性：如果您断电或软件崩溃，正在进行的数据库事务会发生什么情况？如果你有耐用性，答案是“没什么——它们都是安全的”。数据库通过使用一种叫做“撤消/重做日志”的东西来做到这一点，在这种情况下，您对数据库所做的每一件小事都会首先被记录下来（为了安全起见，通常在单独的磁盘上），这样您就可以在发生故障后重建当前状态。没有它，上面的其他属性就没什么用了，因为你永远不能 100% 确定崩溃后事情会保持一致。
这些事情对你来说很重要吗？答案与您正在执行的事务类型以及在失败情况下您想要的保证有关。很可能在某些情况下（例如只读数据库）您不需要这些，但是一旦您开始做任何不平凡的事情，并且发生了一些不好的事情，您就会希望自己拥有它们。也许你可以在任何意外发生时恢复到备份，但我的猜测是它不是。
还要注意，放弃所有这些保护措施并不意味着您的数据库性能会更好；事实上，可能恰恰相反。这是因为现实世界的 DBMS 软件也有大量代码来优化查询性能。因此，如果您在 SimpleDB 上编写一个连接 6 个表的查询，请不要假设它会找出运行该查询的最佳方式——您最终可能要等待数小时才能完成，而商业 DBMS 可以使用索引哈希连接并在 0.5 秒内得到它。您可以采取无数小技巧来优化查询性能，相信我，当它们消失时，您会非常想念它们。
所有这些都不是对 SimpleDB 的打击。从author of the software 获取它：“虽然它是一个很棒的教学工具，但我无法想象有人愿意将它用于其他任何事情。”
【讨论】：