简体繁体 English

使用锁插入B +树

[英]Inserting into B+ tree using locks

原文 2015-11-28 08:29:48 6 1 database/ multithreading/ b-tree

I am trying to figure out how to insert an item into a B+ tree using locks and don't really understand the theory behind it. 我试图弄清楚如何使用锁将项目插入B +树，但我并不真正了解其背后的理论。

So for searching, my view is that I put a lock on the root node, and then decide which child node I should go to and lock it, at this point I can release the parent node and continue this operation until I reach the leaf node. 因此，对于搜索，我的看法是，我在根节点上放了一个锁，然后决定应该去哪个子节点并对其进行锁定，这时我可以释放父节点并继续执行此操作，直到到达叶节点为止。

But inserting is a lot more complicated because I can't allow any other threads to interfere with the insertion. 但是插入要复杂得多，因为我不允许任何其他线程干扰插入。 My idea is put a lock on each node along the path to the leaf node but putting that many locks is quite expensive, and then the question I have is what happens when the leaf node splits because it is too large? 我的想法是在到叶子节点的路径上的每个节点上放置一个锁，但是放置那么多锁非常昂贵，然后我要问的是，当叶子节点因太大而分裂时会发生什么？

Does anyone know how to properly insert an item into a B+ tree using locks? 有人知道如何使用锁将项目正确插入B +树吗？

1 个解决方案

There are many different strategies for dealing with locking in B-Trees in general; 通常，有许多不同的策略可用于处理B树中的锁定。 most of these actually deal with B+Trees and its variations since they have been dominating the field for decades. 由于它们已经在该领域占据主导地位，因此大多数实际上都涉及B + Tree及其变体。 Summarising these strategies would be tantamount to summarising the progress of four decades; 总结这些战略，就等于总结了四个十年的进展； it's virtually impossible. 这几乎是不可能的。 Here are some highlights. 这里有一些亮点。

One strategy for minimising the amount of locking during initial descent is to lock not the whole path starting from the root, but only the sub-path beginning at the last 'stable' node (ie a node that won't split or merge as a result of the currently planned operation). 最小化初始下降过程中锁定量的一种策略是，不锁定从根开始的整个路径，而是仅锁定从最后一个“稳定”节点（即，不会分裂或合并为一个节点）开始的子路径。当前计划的操作的结果）。

Another strategy is to assume that no split or merge will happen, which is true most of the time anyway. 另一种策略是假设不会发生拆分或合并，这在大多数情况下都是正确的。 This means the descent can be done by locking only the current node and the child node one will descend into next, then release the lock on the previously 'current' node and so on. 这意味着可以通过仅锁定当前节点来完成下降，子节点将下降到下一个节点，然后释放先前在“当前”节点上的锁定，依此类推。 If it turns out that a split or merge is necessary after all then re-descend from the root under a heavier locking regime (ie path rooted at last stable node). 如果事实证明毕竟有必要进行拆分或合并，则在较重的锁定机制（即，根植于最后一个稳定节点的路径）下从根目录重新下降。

Another staple in the bag of tricks is to ensure that each node 'descended through' is stable by preventative splitting/merging; 技巧包中的另一个主要目的是通过预防性的拆分/合并来确保每个“下降的节点”都是稳定的。 that is, when the current node would split or merge under a change bubbling up from below then it gets split/merged right away before continuing the descent. 就是说，当当前节点在从下面冒泡的更改下拆分或合并时，它会在继续下降之前立即拆分/合并。 This can simplify operations (including locking) and it is somewhat popular in reinventions of the wheel - homework assignments and 'me too' implementations, rather than sophisticated production-grade systems. 这可以简化操作（包括锁定），并且在重新设计轮子时颇为流行-作业分配和“我也是”实现，而不是复杂的生产级系统。

Some strategies allow most normal operations to be performed without any locking at all but usually they require that the standard B+Tree structure be slightly modified; 一些策略允许执行大多数正常操作而没有任何锁定，但是通常它们需要对标准B + Tree结构进行一些修改； see B-link trees for example. 例如，请参见B链接树。 This means that different concurrent threads operating on the tree can 'see' different physical views of this tree - depending on when they got where and followed which link - but they all see the same logical view. 这意味着在树上操作的不同并发线程可以“查看”该树的不同物理视图-取决于它们何时到达何处以及遵循哪个链接-但它们都看到相同的逻辑视图。