X-Git-Url: http://www2.svjatoslav.eu/gitweb/?p=sixth-data.git;a=blobdiff_plain;f=doc%2Findex.html;h=0c9559e4a8b4b6c9c002cd8815be43cff136c11e;hp=28f924f76fc0583f20e9a4a859579d8fe4f49dcf;hb=c2e5bc51afcb4776720ff274596bd68595f793d7;hpb=bb7b2daf4049f53eefbde9912daca7f31a3b6717
diff --git a/doc/index.html b/doc/index.html
index 28f924f..0c9559e 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -2,7 +2,7 @@
Sixth - system for data storage, computation, exploration and interaction
-
+
@@ -226,19 +226,22 @@ License or later as published by the Free Software Foundation.
-
1 Vision / goal
+
1 Vision / goal
-Provide versioned, clustered, flexible, object-relational database
-functionality for the Sixth computation engine.
+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
+
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.
@@ -250,6 +253,8 @@ memory.
+
+
@@ -278,98 +283,61 @@ memory.
-
-
-
-
-
-
1.2 Solution (the big idea)
-
-
-I see 4D data structure.
-
-
-
-
-
-
-
-
-Dimensions:
-
+
Brain (appears to have more than 3D dimensional design. Food for
+thought…)
-
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)
-
Why not to partition/(load balance) as required across networked
-physical computers along arbitrary dimension(s) declared above ?
+
From there comes following idea: 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.
-
-
-Indexing (for fast searching):
-
-
-
Why not to index along arbitrary dimensions (as required) ?
-
-
-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.
-