directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From elecha...@apache.org
Subject svn commit: r1592442 - /directory/site/trunk/content/mavibot/user-guide/7.1-logical-structure.mdtext
Date Mon, 05 May 2014 04:07:25 GMT
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 :
 
 ![Managed references](images/managedReferences.png)
 



Mime
View raw message