+ 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:
+ 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]].