7 ms·
Whether through Datomic or something else, it seems like some version of "database-as-a-value" (as described by Rich Hickey) is bound to happen. We're keeping i
by ryanbrush 13y ago
Whether through Datomic or something else, it seems like some version of "database-as-a-value" (as described by Rich Hickey) is bound to happen. We're keeping immutable version histories of as much as our hardware and systems will allow, from source code management through other types of media. Why in the world wouldn't we do this with our data if we could?
It'll be interesting to see how this plays out. Widespread adoption of technology tends to follow a path of least resistance. Does Datomic offer a simple enough path to pull many people over? I also know many of us have a preference for building on open source systems; will this be an obstacle for Datomic?
- t0mas88 13y agoTake a look at Event Sourcing, commonly used with CQRS. The approach is indeed to store data as change-events in an event-store (which could by a SQL database or NoSQL store, that depends on your needs) and then built one or more views (separate databases, Lucene indexes, files, anything really) to service the type of requests that the application handles. For an example of CQRS with Event Sourcing in Java: http://axonframework.org http://axonframework.org
- dm3 13y agoThere is also http://geteventstore.com/ http://geteventstore.com/ - an immutable event database by one of the main CQRS aficionados - Greg Young. BTW, clustered HA setup has been opensourced very recently. Really solid and fun to work with.
- strictfp 13y agoAnd there is also the old-school http://prevayler.org/ http://prevayler.org/ :)
- strictfp 13y agoSQL databases also do this. They have events called 'SQL statements' which are written to a 'journal' and applied to the domain which resides in the 'tables' of the database :)
- Tuna-Fish 13y agoYou seem to not understand the point. SQL databases don't count because these mechanisms are not visible, and the programming model is changing data in place. No-one really cares how DB's are implemented under the hood, we just care about the programming model. (And speed, CAP, ACID, etc...)
- strictfp 13y agoI do get the point, in fact I'm building such an app right now, but my statement is still true and I find that quite amusing.
- jimbokun 13y agoGiven the underlying architecture of most relational databases, is it realistically possible to do "point in time queries", without requiring playing back the entire log history into a clean database up to the point in time you want? That's not going to be very efficient. I've only seen SQL logs presented as solutions to replication and disaster recovery, not point in time functionality. What I'm getting at, is it even possible in principle to expose part of the inner workings of some relational database systems to get this kind of capability?
- strictfp 13y agoSnapshotting and log replay should be fairly straightforward, if you save all sql statements in their entirety. Snapshots would stop the world, which might pose a problem, but I presume this is no different to other event sourcing solutions. Given the concurrency of a db, I'm also not sure that there's a strict ordering of all incoming statements. Edit: Seems like at least Oracle is already doing this: http://en.wikipedia.org/wiki/Redo_log http://en.wikipedia.org/wiki/Redo_log
- twic 13y agoNot only is this possible, Oracle has had exactly that feature since 2002: http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_flashback.htm#i1008579 http://docs.oracle.com/cd/E11882_01/appdev.112/e17125/adfns_...