Described storage layers.
authorSvjatoslav Agejenko <svjatoslav@svjatoslav.eu>
Tue, 26 Sep 2017 19:13:51 +0000 (22:13 +0300)
committerSvjatoslav Agejenko <svjatoslav@svjatoslav.eu>
Tue, 26 Sep 2017 19:13:51 +0000 (22:13 +0300)
doc/index.html
doc/index.org

index c719c14..b116d4e 100644 (file)
@@ -2,7 +2,7 @@
 <html lang="en">
 <head>
 <title>Sixth - system for data storage, computation, exploration and interaction</title>
 <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">
 <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>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
 <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:
 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>
-<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>
 </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.
 the system decide at runtime which data to keep in what kind of
 memory.
-</p>
+</li>
+</ul>
 </li>
 </ul>
 </div>
 </li>
 </ul>
 </div>
@@ -415,8 +413,38 @@ amount of work contributed for book by given author (point).
 </ul>
 </div>
 </div>
 </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>
 
 <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-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>
 </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>
 </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>
 <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>
index caa29aa..a686ef5 100644 (file)
@@ -36,15 +36,19 @@ data storage engine for the [[http://www2.svjatoslav.eu/gitbrowse/sixth/doc/inde
 
 + Speaking of traditional relational database and object oriented
   business applications:
 
 + Speaking of traditional relational database and object oriented
   business applications:
+
   + I hate object-relational impedance mismatch.
 
   + I don't like to convert data between persistent database and
   + I hate object-relational impedance mismatch.
 
   + I don't like to convert data between persistent database and
-  runtime objects for every transaction. How about creating united
-  database/computation engine instead to:
-  + Eliminate constant moving and converting of data between 2 systems.
+    runtime objects for every transaction. How about creating united
+    database/computation engine instead to:
+
+  + Eliminate constant moving and converting of data between 2 systems
+    and make computing happen close to where the data is stored.
+
   + Abstract away difference between RAM VS persistent storage. Let
   + Abstract away difference between RAM VS persistent storage. Let
-  the system decide at runtime which data to keep in what kind of
-  memory.
+    the system decide at runtime which data to keep in what kind of
+    memory.
 
 * Inspiration
 + Relational databases:
 
 * Inspiration
 + Relational databases:
@@ -130,6 +134,25 @@ Alternatively:
     + Point location along particular (book) dimension corresponds to
       amount of work contributed for book by given author (point).
 
     + Point location along particular (book) dimension corresponds to
       amount of work contributed for book by given author (point).
 
+** Layered architecture
++ layer 1 :: disk / block storage / partition
+
++ layer 2 :: 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.
+
++ layer 3 :: 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)
+
++ layer 4 :: Implements arbitrary dimensional multiverse.
+
++ layer 5 :: Distributed computation engine.
 
 * Current status
 - More or less defined [[id:f6764282-a6f6-44e6-8716-b428074dd093][Vision / goal]].
 
 * Current status
 - More or less defined [[id:f6764282-a6f6-44e6-8716-b428074dd093][Vision / goal]].