可伸缩数据库，索引的最佳并发模型？

Question

我很喜欢并发技术，这些技术相对容易实现，并且适用于缩放（多节点）。

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

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

更新

我在NoSQL的储存和模型有趣。

Answer 1

你需要仔细考虑你正在寻找的东西。 “可伸缩”是指数据库的大小吗？读者人数？同时作家的数量？读者在没有内在矛盾的作家的情况下的吞吐量？通过“索引”，你的意思是像btree这样的传统的完全有序的索引，还是哈希算法呢？还有，读者和作者想要达到什么样的一致性？

以前的评论建议散列，如果你不需要像btree一样的有序索引，那就很好，因为散列操作会将密钥空间分割成单独的部分，以便同时执行操作避免交互。另一方面，范围查询需要某种类型的树索引，它存在问题，因为单个更新可以在调整索引时锁定所有其他查询。传统的解决方案http://en.wikipedia.org/wiki/Multiversion_concurrency_control

Answer 2

在数据库中最大化并发能力的理想方法是使用带有散列键的“稀疏填充”表。这可以通过PK（或可以让你快速到达PK的代理）即时检索记录，并且几乎可以消除冲突。没有必要读取索引以确定记录在表中“居住”的位置，因为其位置可以是来自散列PK的计算的。然而，通过这种方式最大限度地提高并发能力，您可能会遭受一些其他折衷，例如无法快速检索某个特定邮编的所有记录，或无法按某个日期值立即排序表。快速获取给定邮政编码的所有记录，或通过日期列立即排列行，通常将这些记录进行物理分组，使它们在磁盘上保持连续，以避免过度的磁盘颠簸。使用散列键的人口稀疏的表格可能涉及在获取记录的组（例如纽约所有客户）的组中，而在获取单个记录时（客户＃123456）擅长的情况下，显着的磁盘颠簸。

编辑：我应该补充说，在这种散列键稀疏填充的数据库中，找到复合主键如ZIPCODE * CUSTOMERNUMBER并不罕见，以便给定邮编中的所有客户最终都存储在与人口稀少的表格大致相同的区域;这是为了尽量减少运行邮编驱动报告时的抖动。因此，有方法可以缓解方法的不利影响，同时保持极低的冲突率和无索引所需的记录提取。

编辑2：假设你想让电子邮件地址成为PK，但并不希望将来自AOL或YAHOO或GOOGLE的每个人的记录聚集在备用填充表的相同区域中，在那里“膨胀”，就像吞下猪的水蟒一样。您可以使用左加权主键哈希算法来更加强调@左侧的值。但是，如果您要使用数字顺序PK，则可以使用右加权算法来消除此类凸起。