directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r908047 - in /websites/staging/directory/trunk/content: ./ mavibot/user-guide/7.1-logical-structure.html
Date Mon, 05 May 2014 04:07:32 GMT
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>



Mime
View raw message