You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by el...@apache.org on 2014/05/05 06:07:25 UTC
svn commit: r1592442 -
/directory/site/trunk/content/mavibot/user-guide/7.1-logical-structure.mdtext
Author: elecharny
Date: Mon May 5 04:07:25 2014
New Revision: 1592442
URL: http://svn.apache.org/r1592442
Log:
fixed a few typoes
Modified:
directory/site/trunk/content/mavibot/user-guide/7.1-logical-structure.mdtext
Modified: directory/site/trunk/content/mavibot/user-guide/7.1-logical-structure.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/mavibot/user-guide/7.1-logical-structure.mdtext?rev=1592442&r1=1592441&r2=1592442&view=diff
==============================================================================
--- directory/site/trunk/content/mavibot/user-guide/7.1-logical-structure.mdtext (original)
+++ directory/site/trunk/content/mavibot/user-guide/7.1-logical-structure.mdtext Mon May 5 04:07:25 2014
@@ -46,11 +46,11 @@ The below diagram shows the logical repr
A persistent *BTree* is a *BTree* which can be flushed to disk on demand. The *BTree* is a in-Memory *BTree*, but while closing it, then content of the latest revision is serialized on disk. The data can be loaded while opening a persistent BTree.
-Othe than that, there is no difference between an in-memory *BTree* and a persistent *BTree*.
+Other than that, there is no difference between an in-memory *BTree* and a persistent *BTree*.
## Managed BTrees
-Managed *BTree*s are very different : data is guaranteed to be preserved on disk after each modifciation, even when the program crashes, it is guaranteed that the disk will contain everything needed to recover the *BTree* to the state it was in just before the crash.
+Managed *BTree*s are very different : data is guaranteed to be preserved on disk after each modification, even when the program crashes, it is guaranteed that the disk will contain everything needed to recover the *BTree* to the state it was in just before the crash.
This is important to understand that in managed mode, not all *BTree*s (of a mavibot database) are kept in memory. In other words, all nodes, except the *root* node, of a BTree may or may not be present at the time of accessing. **Mavibot** will fetch these nodes from disk when needed.
@@ -59,7 +59,7 @@ Obviously this approach has both pros an
Pros :
* there is no limit on the number of elements one can store in a BTree, except on the available disk space
* A *BTree* will always be consistent, even if there was a crash
-* data durability is gauranteed
+* data durability is guaranteed
Cons :
* reads might be costly when the data is not present in memory, due to fetching data from disk
@@ -71,7 +71,7 @@ Also note that we use internal cache to
Managed *BTree*s are stored using *Nodes* and *Leaves*. A *Node* contains only keys or references to underlaying nodes or leaves. A *Leaf* contains keys and values. As we don't want to eat too much memory, the references to nodes, leaves, keys and values are stored as offset, read and translated to java objects on demand. For instance, we keep an offset to a key until someone needs to access the key, then we deserialize this key and store it in memory. This is the very same for references to nodes, leaves or values.
-Here is a schematic describing this structure :
+Here is a picture describing this structure :
