X-Git-Url: http://www2.svjatoslav.eu/gitweb/?p=sixth-data.git;a=blobdiff_plain;f=doc%2Findex.org;h=a686ef5803997c2f285c6bd6a55eb9125037cb95;hp=caa29aa68ff459f2cf4c98dfb5808582001817b0;hb=501a45a40586b9bc32c5b228661bfa49a583f548;hpb=b382105757c3d9a2bb528fa8e4218354feff2429

diff --git a/doc/index.org b/doc/index.org
index caa29aa..a686ef5 100644
--- a/doc/index.org
+++ b/doc/index.org
@@ -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:
+
   + 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:
@@ -130,6 +134,25 @@ Alternatively:
     + 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]].