<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">
<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>
</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>
<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>
</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>
+ 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
- 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
- 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:
+ 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]].
projects / sixth-data.git / commitdiff