From: Svjatoslav Agejenko Date: Tue, 26 Sep 2017 19:13:51 +0000 (+0300) Subject: Described storage layers. X-Git-Url: http://www2.svjatoslav.eu/gitweb/?a=commitdiff_plain;h=501a45a40586b9bc32c5b228661bfa49a583f548;p=sixth-data.git Described storage layers. --- diff --git a/doc/index.html b/doc/index.html index c719c14..b116d4e 100644 --- a/doc/index.html +++ b/doc/index.html @@ -2,7 +2,7 @@ Sixth - system for data storage, computation, exploration and interaction - + @@ -236,27 +236,25 @@ data storage engine for the
  • 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.
      • -
    • Abstract away difference between RAM VS persistent storage. Let + +
    • 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. -

    +
    • + @@ -415,8 +413,38 @@ amount of work contributed for book by given author (point). - +
    +

    3.4 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. +
    +
    +
    +
    +

    4 Current status

    @@ -493,6 +521,7 @@ applications.
  • 3.1. Distributed computation and data storage
  • 3.2. Mapping of hyperspace to traditional object-oriented model
  • 3.3. Handling of relations
    • +
  • 3.4. Layered architecture
  • 4. Current status
    • @@ -503,7 +532,7 @@ applications.
    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]].