X-Git-Url: http://www2.svjatoslav.eu/gitweb/?a=blobdiff_plain;f=doc%2Findex.org;h=081e95b6a52be3abc34efdd9428d811bb8db99d6;hb=32e305d7f189ddd3a6e62a2abf29065187cc75b2;hp=62f29575f2468c2c9565251a1a431d65a01aadf9;hpb=2316187f481ff4854fd93e381e6b1c802cd5bac0;p=sixth-data.git diff --git a/doc/index.org b/doc/index.org index 62f2957..081e95b 100644 --- a/doc/index.org +++ b/doc/index.org @@ -14,7 +14,7 @@ - Homepage: http://svjatoslav.eu - Email: mailto://svjatoslav@svjatoslav.eu -- [[http://svjatoslav.eu/programs.jsp][other applications hosted at svjatoslav.eu]] +- [[http://www.svjatoslav.eu/programs.jsp][other applications hosted at svjatoslav.eu]] * (document settings) :noexport: @@ -28,20 +28,25 @@ #+HTML_HEAD: * Vision / goal -Provide versioned, clustered, flexible, object-relational database -functionality for the [[http://www2.svjatoslav.eu/gitbrowse/sixth/doc/index.html][Sixth computation engine]]. - -+ 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. - -** Inspiration + :PROPERTIES: + :ID: f6764282-a6f6-44e6-8716-b428074dd093 + :END: +Provide versioned, clustered, flexible, distributed, multi-dimensional +data storage engine for the [[http://www2.svjatoslav.eu/gitbrowse/sixth/doc/index.html][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. + +* Inspiration + Relational databases: + Transactional. + Indexable / Quickly searchable. @@ -53,35 +58,60 @@ functionality for the [[http://www2.svjatoslav.eu/gitbrowse/sixth/doc/index.html + (Git as a database: https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/ ) -** Solution (the big idea) -I see 4D data structure. +** Brain + :PROPERTIES: + :ID: d2375acc-af14-4f18-8ad0-7949501178c5 + :END: ++ Appears to have more than 3D dimensional design. Food for + thought...) + + https://singularityhub.com/2017/06/21/is-there-a-multidimensional-mathematical-world-hidden-in-the-brains-computation/ + ++ 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. -[[file:data model.png]] +* Current status +- More or less defined [[id:f6764282-a6f6-44e6-8716-b428074dd093][Vision / goal]]. -Dimensions: -+ List of all the objecs in the system (rows). -+ List of all declared unique object fields (columns). -+ List of all historical transactions/commits/versions (think of - sheets of paper). -+ List of all concurrently running branches/threads. Branches can - appear and merge over time as needed. -+ (Every cell is concrete field value within an object) +- Collected some [[id:d2375acc-af14-4f18-8ad0-7949501178c5][ideas]]. -Partitioning/clustering: -+ Why not to partition/(load balance) as required across networked - physical computers along arbitrary dimension(s) declared above ? +- 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. -Indexing (for fast searching): -+ Why not to index along arbitrary dimensions (as required) ? +* See also +Interesting or competing projects with good ideas: -Further optimizations: -+ In current early stage, trying to focus on minimum possible set of - features that would provide maximum possible set of power/benefit :) -+ Once featres are locked. Anything can be optimised. Optimization for - size (deduplication) can be solved using Git style content - addressible storage mechanism. ++ GRAKN.AI: database in the form of a knowledge graph that uses + machine reasoning to simplify data processing challenges for AI + applications. + + https://grakn.ai/ -* Current status -- Implemented very simple persistent key-value map. ++ Gemstone/S based on Smalltalk. + + http://esug.org/data/ESUG2015/3%20wednesday/1100-1130%20SQL%20Queries%20on%20Smalltalk%20Objects/SQL%20Queries%20in%20Smalltalk%20(James%20Foster).pdf -Long term goal is to implement more advanced features on top of this. ++ Magma distributed database in Smalltalk. + + http://wiki.squeak.org/squeak/2665