svn commit: r908047 - in /websites/staging/directory/trunk/content: ./ mavibot/user-guide/7.1-logical-structure.html

[bu...@apache.org]

Author: buildbot
Date: Mon May  5 04:07:32 2014
New Revision: 908047

Log:
Staging update by buildbot for directory

Modified:
    websites/staging/directory/trunk/content/   (props changed)
    websites/staging/directory/trunk/content/mavibot/user-guide/7.1-logical-structure.html

Propchange: websites/staging/directory/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon May  5 04:07:32 2014
@@ -1 +1 @@
-1592385
+1592442

Modified: websites/staging/directory/trunk/content/mavibot/user-guide/7.1-logical-structure.html
==============================================================================
--- websites/staging/directory/trunk/content/mavibot/user-guide/7.1-logical-structure.html (original)
+++ websites/staging/directory/trunk/content/mavibot/user-guide/7.1-logical-structure.html Mon May  5 04:07:32 2014
@@ -164,22 +164,22 @@
 <p><img alt="In-Memory BTree" src="images/InMemoryBTree.png" /></p>
 <h2 id="persistent-btrees">Persistent BTrees</h2>
 <p>A persistent <em>BTree</em> is a <em>BTree</em> which can be flushed to disk on demand. The <em>BTree</em> is a in-Memory <em>BTree</em>, but while closing it, then content of the latest revision is serialized on disk. The data can be loaded while opening a persistent BTree.</p>
-<p>Othe than that, there is no difference between an in-memory <em>BTree</em> and a persistent <em>BTree</em>.</p>
+<p>Other than that, there is no difference between an in-memory <em>BTree</em> and a persistent <em>BTree</em>.</p>
 <h2 id="managed-btrees">Managed BTrees</h2>
-<p>Managed <em>BTree</em>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 <em>BTree</em> to the state it was in just before the crash.</p>
+<p>Managed <em>BTree</em>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 <em>BTree</em> to the state it was in just before the crash.</p>
 <p>This is important to understand that in managed mode, not all <em>BTree</em>s (of a mavibot database) are kept in memory. In other words, all nodes, except the <em>root</em> node, of a BTree may or may not be present at the time of accessing. <strong>Mavibot</strong> will fetch these nodes from disk when needed.</p>
 <p>Obviously this approach has both pros and cons :</p>
 <p>Pros :
 <em> there is no limit on the number of elements one can store in a BTree, except on the available disk space 
 </em> A <em>BTree</em> will always be consistent, even if there was a crash
-* data durability is gauranteed</p>
+* data durability is guaranteed</p>
 <p>Cons :
 <em> reads might be costly when the data is not present in memory, due to fetching data from disk 
 </em> accessing the data from disk requires an extra layer of accessor code, this costs some extra memory</p>
 <p>Here, this is just a question of tradeoff : depending on the existing memory size, and the level of robustness needed, one may decide to go for an in-memory <em>BTree</em>, a persistent <em>BTree</em> or a managed one. Most of the time, though, managed <em>BTree</em> is what you want to use.</p>
 <p>Also note that we use internal cache to speed up the data access. This cache and its size can be configured.</p>
 <p>Managed <em>BTree</em>s are stored using <em>Nodes</em> and <em>Leaves</em>. A <em>Node</em> contains only keys or references to underlaying nodes or leaves. A <em>Leaf</em> 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.</p>
-<p>Here is a schematic describing this structure :</p>
+<p>Here is a picture describing this structure :</p>
 <p><img alt="Managed references" src="images/managedReferences.png" /></p>
 <p>In this BTree, only two pages are present in memory : one node and one leaf. In these pages, the keys aren't yet objects, they are pointing to the page's raw data, except for the <strong>D</strong> key and it's value, they were loaded and deserialized.</p>
 <p>Here each element, contains an offset and the byte[] of the serialized value or the deserialized value if the value has already been accessed.</p>