0

我对相对容易实现并且适合扩展（多节点）的并发技术很感兴趣。

另外，如果您知道一些更高级的算法，请提供一些信息。

希望这个话题对其他人有用。谢谢！

更新

我对 nosql 存储和模型很感兴趣。

4

2 回答 2

0

在数据库中最大化并发能力的理想方法是使用带有散列键的“稀疏填充”表。这允许通过 PK（或可以让您快速到达 PK 的代理）即时检索记录，并且几乎消除了冲突。无需读取索引来确定记录在表中的“位置”，因为它的位置可以从散列的 PK中计算出来。然而，通过最大化以这种方式的并发能力，您可能会遭受其他一些权衡，例如无法快速检索特定邮政编码的所有记录，或者无法立即按某个日期值对表进行排序。快速获取给定邮政编码的所有记录，或按日期列立即对行进行排序，通常会将这些记录进行物理分组，使它们在磁盘上连续，以避免过度的磁盘抖动。当获取记录组（例如纽约的所有客户）时，带有散列键的稀疏填充表可能会导致严重的磁盘抖动，而在获取单个记录时它会表现出色（客户＃123456）。

编辑：我应该补充一点，在这种散列键稀疏的数据库中，找到诸如 ZIPCODE*CUSTOMERNUMBER 之类的复合主键并不罕见，因此给定邮政编码中的所有客户最终都存储在大致相同的区域人烟稀少的桌子；这样做是为了在运行邮政编码驱动的报告时最大限度地减少颠簸。因此，有一些方法可以减轻该方法的不利影响，同时保持其极低的冲突率和不需要索引的记录获取。

EDIT2：假设您想将电子邮件地址设为 PK，但又不想将来自 AOL、YAHOO 或 GOOGLE 的每个人的记录聚集在备用填充表的同一区域中，从而导致“凸起”在那里，就像吞下猪的蟒蛇。您可以使用左加权主键散列算法来更加强调 @ 左侧的值。但是，如果您要使用数字顺序 PK，则可以使用右加权算法来消除此类凸起。

于 2011-03-12T13:07:34.187 回答
0

你需要仔细考虑你在寻找什么。“可扩展”是指数据库的大小吗？读者人数？同时作者的数量？在存在非固有冲突的作者的情况下，读者的吞吐量？“索引”是指像 btree 这样的传统全序索引，还是散列？另外，您希望读者和作者之间保持何种程度的一致性？

前面的评论建议使用散列，如果您不需要类似 btree 的有序索引，这非常好，因为散列操作将键空间分成单独的部分，因此同时操作避免了交互。另一方面，范围查询需要某种树索引，这有问题，因为单个更新可以在调整索引时锁定所有其他查询。这个http://en.wikipedia.org/wiki/Multiversion_concurrency_control的传统解决方案

于 2011-03-12T19:25:27.497 回答