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