First, I preface this as I’m reading this thread as an intellectual exercise… I don’t give good odds that this may turn into a practical project since postgres (and other open source DBs) have so much momentum and world-wide support.
I do love to read garrison’s posts all DB related.
Random thoughts:
- Intent?
Is the intent of just something better than mnesia? Lightweight (sqlite-like) native in BEAM? Or like a serious scaling RDBMS along the lines of FoundationDB?
- Question of embedding
a writeup for Any way to embed riak_kv? · OpenRiak · Discussion #23 · GitHub would be enough for me
I can’t find the thread/link, but I think there was something where someone stated that they wouldn’t want to collocate Riak with the app because of “blast radius” boundary, and thus didn’t really build for the embedded case.
I personally would not want to have an app deployment (e.g. fly blue-green deployments) to elevate the risk of database issue, as deploying each to me are different concerns:
- DB deployment or upgrade is an infrastructure issue
- App deployment is application/businessFeatures level.
I still say that the idea of a BEAM-native DB (actually DX usable instead of mnesia) might be a good thing, especially if it takes advantage of BEAM’s uptime/fault capabilities for operational management (e.g. work towards zero-downtime upgrading/downgrading)?
- Temporal Databases
The ability to “rewind” and see the state in the past.
I think that Datomic’s time travel works because it models (turtles all the way down) as statement tuples like RDF’s Subject-Predicate-Value-- They have Entity-Attribute-Value-Transaction. So, to me, Datomic’s unification of Domain Business Modeling with Data (Structural/Persistence) Modeling is what allows the application-developer to have something easily understandable/usable in the time travel.
Whereas, it appears to me that Relational DB implementations (e.g. Postgres) is all about the WAL that is persisting what I think CJ Date might have described as the “internal model”? An impedance mismatch between that and the conceptual level-- This is me (a non-db-dev or researcher) working on hazy memory from past reading.
Where I think I would find more use in Event Sourcing DB where I’m describing at the “Business/Domain” (not CRUD) changes, and then rebuild a custom business-driven view at a point in time IF I ever need to.
And if time travel were important in my use of RDBMS-- I have not regularly needed a native-db temporal time travel capability-- I would think we could model the time-components as distinct columns anyways, use SQL to give me point in time views?
- SQL
Didn’t Andy Pavlo-- gangster by thy name? – say something to the effect of how so many people tried to reinvent or create alt-languages, but everything eventually will consolidate back into SQL, which he implied, just skip the pain and work with SQL?
love reading the above thread.
