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