Described storage layers.
[sixth-data.git] / doc / index.html
index c719c14..b116d4e 100644 (file)
@@ -2,7 +2,7 @@
 <html lang="en">
 <head>
 <title>Sixth - system for data storage, computation, exploration and interaction</title>
-<!-- 2017-07-29 Sat 13:31 -->
+<!-- 2017-09-26 Tue 22:13 -->
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <meta name="generator" content="Org-mode">
@@ -236,27 +236,25 @@ data storage engine for the <a href="http://www2.svjatoslav.eu/gitbrowse/sixth/d
 <ul class="org-ul">
 <li>Speaking of traditional relational database and object oriented
 business applications:
+
 <ul class="org-ul">
 <li>I hate object-relational impedance mismatch.
 </li>
 
 <li>I don't like to convert data between persistent database and
-</li>
-</ul>
-<p>
 runtime objects for every transaction. How about creating united
 database/computation engine instead to:
-</p>
-<ul class="org-ul">
-<li>Eliminate constant moving and converting of data between 2 systems.
 </li>
-<li>Abstract away difference between RAM VS persistent storage. Let
+
+<li>Eliminate constant moving and converting of data between 2 systems
+and make computing happen close to where the data is stored.
 </li>
-</ul>
-<p>
+
+<li>Abstract away difference between RAM VS persistent storage. Let
 the system decide at runtime which data to keep in what kind of
 memory.
-</p>
+</li>
+</ul>
 </li>
 </ul>
 </div>
@@ -415,8 +413,38 @@ amount of work contributed for book by given author (point).
 </ul>
 </div>
 </div>
-</div>
 
+<div id="outline-container-sec-3-4" class="outline-3">
+<h3 id="sec-3-4"><span class="section-number-3">3.4</span> Layered architecture</h3>
+<div class="outline-text-3" id="text-3-4">
+<dl class="org-dl">
+<dt> layer 1 </dt><dd>disk / block storage / partition
+</dd>
+
+<dt> layer 2 </dt><dd>key/value storage. Keys are unique and are dictated by
+storage engine. Value is arbitrary but limited size byte
+array. This layer is responsible for handling disk
+defragmentation and consistency in case of crash
+recovery.
+</dd>
+
+<dt> layer 3 </dt><dd>key/value storage. Keys are content hashes. Values are
+arbitrary but limited size content byte arrays. This
+layer effectively implements content addressable
+storage. Content addressible storage enables GIT-like
+behavior (possibility for competing branches, retaining
+history, transparent deduplication)
+</dd>
+
+<dt> layer 4 </dt><dd>Implements arbitrary dimensional multiverse.
+</dd>
+
+<dt> layer 5 </dt><dd>Distributed computation engine.
+</dd>
+</dl>
+</div>
+</div>
+</div>
 
 <div id="outline-container-sec-4" class="outline-2">
 <h2 id="sec-4"><span class="section-number-2">4</span> Current status</h2>
@@ -493,6 +521,7 @@ applications.
 <li><a href="#sec-3-1">3.1. Distributed computation and data storage</a></li>
 <li><a href="#sec-3-2">3.2. Mapping of hyperspace to traditional object-oriented model</a></li>
 <li><a href="#sec-3-3">3.3. Handling of relations</a></li>
+<li><a href="#sec-3-4">3.4. Layered architecture</a></li>
 </ul>
 </li>
 <li><a href="#sec-4">4. Current status</a></li>
@@ -503,7 +532,7 @@ applications.
 </div></div></div>
 <footer id="postamble" class="">
 <div><p class="author">Author: Svjatoslav Agejenko</p>
-<p class="date">Created: 2017-07-29 Sat 13:31</p>
+<p class="date">Created: 2017-09-26 Tue 22:13</p>
 <p class="creator"><a href="http://www.gnu.org/software/emacs/">Emacs</a> 25.1.1 (<a href="http://orgmode.org">Org-mode</a> 8.2.10)</p>
 </div>
 </footer>