X-Git-Url: http://www2.svjatoslav.eu/gitweb/?a=blobdiff_plain;f=doc%2Findex.html;h=d0f979d5b047cfde09b816345d0080da6f77137e;hb=32e305d7f189ddd3a6e62a2abf29065187cc75b2;hp=8793e4565e2e7e39d3822467b63f6e6002838b0f;hpb=45c3bd94e38fc74268429d4441e730aec28492bf;p=sixth-data.git diff --git a/doc/index.html b/doc/index.html index 8793e45..d0f979d 100644 --- a/doc/index.html +++ b/doc/index.html @@ -1,350 +1,418 @@ - - - + + - - - - Sixth - system for data storage, computation, exploration and interaction - - - - - +Sixth - system for data storage, computation, exploration and interaction + + + + + + + +" + + + -
-

Sixth - system for data storage, computation, exploration and interaction

-
-

Table of Contents

- -
-
- - - -
-

1 Current status

-
-
    -
  • Implemented very simple persistent key-value map.
  • -
- -

- Long term goal is to implement more advanced features on top of this. -

-
-
+
+

Sixth - system for data storage, computation, exploration and interaction

+
+ + + +
+

1 Vision / goal

+
+

+Provide versioned, clustered, flexible, distributed, multi-dimensional +data storage engine for the Sixth computation engine. +

+ +
    +
  • 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 +the system decide at runtime which data to keep in what kind of +memory. +
      • +
      +
    • +
    +
  • +
-
-

Author: Svjatoslav Agejenko

-

Created: 2016-08-03 Wed 23:45

-

Validate

+ +
+

2 Inspiration

+
+
    +
  • Relational databases: +
      +
    • Transactional. +
    • +
    • Indexable / Quickly searchable. +
    • +
    +
  • + +
  • Git (version control system) + +
  • +
+
+ +
+

2.1 Brain

+
+
    +
  • Appears to have more than 3D dimensional design. Food for +thought…) + +
  • + +
  • From there come following ideas: +
      +
    • Maybe every problem can be translated to geometry (use any shapes +and as many dimensions as you need). Solution(s) to such problems +would then appear as relatively simple search/comparison/lookup +results. As a bonus, such geometrical *data storage* AND +*computation* can be naturally made in *parallel* and +*distributed*. That's what neurons in the brain appear to be doing +! :) . Learning means building/updating the model (the hard +part). Question answering is making (relatively simple) lookups +(geometrical queries) against the model. +
    • + +
    • Mapping of hyperspace to traditional object-oriented programming +model: +
        +
      • Object is a point in space (universe). Each object member +variable translates to its own dimension. That is: if class +declares 4 variables for an object, then corresponding object +can be stored as a single point inside 4 dimensional +space. Variable values translate to point coordinates in +space. That is: Integer, floating point number and even boolean +and string can be translated to linear value that can be used as +a coordinate along particular dimension. +
      • + +
      • Each class declares its own space (universe). All class +instances (objects) are points inside that particular +universe. References between objects of different types are +hyperlinks (portals) between different universes. +
      • +
      +
    • +
    +
  • +
+
+
+
+ +
+

3 Current status

+
+
    +
  • More or less defined Vision / goal. +
  • + +
  • Collected some ideas. +
  • + +
  • Implemented very simple persistent key-value map. +
      +
    • Long term goal is to use it as a backing storage engine and +implement more advanced features on top of this. +
    • +
    +
  • +
+
+
+ +
+

4 See also

+
+

+Interesting or competing projects with good ideas: +

+ + +
+
+
+