我对并发技术感兴趣，它们相对容易实现，适合扩展（多个节点）。
如果您了解一些更高级的算法，请提供一些信息。
希望这个主题对其他人有用。 谢谢！
更新
我对nosql存储和模型感兴趣。
答案 0 :(得分：0)
在数据库中最大化并发功能的理想方法是使用带有散列键的“稀疏填充”表。这允许通过PK（或可以快速到达PK的代理）即时检索记录，并且几乎消除了冲突。无需读取索引即可确定记录在表中“存在”的位置，因为其位置可以从散列PK中计算。但是，通过以这种方式最大化并发功能，您可能会遭受其他一些折衷，例如无法快速检索特定邮政编码的所有记录，或者无法立即订购表格按某个日期值。快速获取给定邮政编码的所有记录，或者通过日期列立即对行进行排序，通常会对那些使它们在磁盘上连续的记录进行物理分组，以避免过多的磁盘抖动。当获取记录的组（例如纽约的所有客户）时，具有散列密钥的稀疏填充表可能涉及显着的磁盘抖动，而当获取单个记录时（客户＃123456）它具有优异性。
编辑：我应该在这样的散列密钥稀疏填充的数据库中添加它，找到复合主键（例如ZIPCODE * CUSTOMERNUMBER）以使得给定邮政编码中的所有客户最终都被大致存储并不罕见人口稀少的桌子的同一区域;这样做是为了在运行zipcode驱动的报告时最大限度地减少颠簸。因此，有一些方法可以减轻该方法的不利影响，同时保留其极低的冲突率和无索引要求的记录提取。EDIT2：假设您想要将电子邮件地址设为PK，但又不想将来自AOL或YAHOO或GOOGLE的所有人的记录聚集在备用填充表的同一区域中，从而导致那里有“凸起”，就像吞下猪的蟒蛇一样。您可以使用左加权主键散列算法来更加强调@左侧的值。但是如果你使用数字顺序PK，你可以使用右加权算法来消除这种凸起。
答案 1 :(得分：0)
你需要仔细思考你正在寻找什么。 “可扩展”是指数据库的大小吗？读者人数？同时写作者的数量？在没有固有冲突的作家面前读者的吞吐量？通过“索引”，你的意思是传统的完全有序的索引，如btree，还是哈希？另外，你想在读者和作家中达到什么程度的一致性？
之前的评论建议使用散列，如果你不需要类似btree的有序索引，这是非常好的，因为散列操作将键空间分成不同的部分，因此同时操作可以避免交互。另一方面，范围查询需要某种树索引，这会产生问题，因为单个更新可以在调整索引时锁定所有其他查询。这个http://en.wikipedia.org/wiki/Multiversion_concurrency_control
的传统解决方案