4 ms·

Mostly when you need a ledger like functionality to your data. Datomic preserves the history of all the changes by design so it is very easy to reconstruct the

Mostly when you need a ledger like functionality to your data. Datomic preserves the history of all the changes by design so it is very easy to reconstruct the history of changes to your data. If this describes the majority of your problem space then Datomic is a good fit. Otherwise I would stick to a popular RDBMS like Postgres to leverage the community behind it. You will have a much easier time interacting with a well understood open source engine.

emccue 5y ago
I think this is true - you will have an easier time not blazing new trails in general - but the need of ledger-like functionality isn't the distinguishing factor. Preserving the history of all changes isn't just for reconstructing that history later, it's a central component in maintaining ACID while allowing for distributed readers. Datomic has a singular transactor - node that can accept writes. So all transactions happen in sequence and consistency is maintained within the data model. So your database goes DB (0 transactions) -> DB' (1 transaction committed) -> DB'' (2 transactions committed) With normal databases, when DB'' is created, DB' is lost. You change stuff in place. This means that anyone wanting to observe a consistent view of the database needs to coordinate with writes. This is why SQL dbs are single giant machines. For Cassandra, Dynamo, Mongo, etc you still change stuff in place, but you just accept that things will be potentially inconsistent ("eventually consistent") for your readers. Once you drop that part of ACID you can scale your readers and your writers arbitrarily. With Datomic DB, DB', and DB'' are still maintained. If you want to read the database "now" you can get a handle to the state that your reader thinks is the most recent. This might not be behind the absolute newest state that the transactor knows about, but it is still a consistent view of the database. Its because of this you can scale your read nodes independently of the system. Because if you are reading DB' you know the value of that won't change you can load chunks of the indexes into the memory for caching and even embed the querying into the application making queries. The proprietary-ness and JVM-ness of Datomic are its biggest weaknesses. I choose to believe those weaknesses can be addressed.
- huahaiy 5y ago
  Every database that implements MVCC does this, that means most ACID databases. So "reading a consistent view" is not unique for Datomic.
- Nihilartikel 5y ago
  I'm waiting to have a need to use it, but XTDB is a nice fully open bitemporal 'lite' Datomic that I have been keeping an eye on.
- runekaagaard 5y ago
  Ah yes, makes me remember the amazing talk by Rich Hickey called "The database as a Value" [1]. I felt like my brain was reorganized after watching it. The simplicity of Datomic is very appealing, it's just a timestamped series of EAV entries, and some fancy indexing. Avoiding the latency (the database over there issue) sounds like a big win. Most of the simplicity is made possible by only having one single synchronous writer which is a major drawback you have to be able to live with. Some write-heavy applications would struggle. Related to the timetravel feature I've bookmarked a blog post by Valentin Waeselynck where he talks about some of the misconceptions and drawbacks. [2]. My company have a not super-great setup with triggers on MySQL, and have longed for MariaDBs SQL 2011 compliant Temporal Tables which looks very interesting [3]. I guess an advantage with Datomic is that you don't have to create an entire table history row when all you want is to update a single field. I was interested enough in Datomic that I started building a Python bridge but never finished it [4]. An added bonus was that I learned about the Transit serialization format which was ALSO super inspiring [5]. [1] https://www.youtube.com/watch?v=D6nYfttnVco [2] https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html [3] https://mariadb.com/resources/blog/temporal-tables-part-1/ [4] https://github.com/runekaagaard/brygge/blob/master/src/jolle/example.py [5] https://cognitect.com/blog/2014/7/22/transit
john567 5y ago
This is true but it's a false premise. You have history but it's clunky to work with. You won't be able to "source" and recreate the past without some work and unexpected things will happen when you "source" the past with the most recent code. It useful but the history aspect is easily misunderstood.
- emccue 5y ago
  In this respect XTDB has a more directly useful model
- blain_the_train 5y ago
  Can you explain what "source" means?
  - john567 5y ago
    Oh, yeah, think of event sourcing. You have a series of events leading up (aggregate) into some state. This can be done in different ways but with Datomic you can request a point in time database. This database doesn't exist so it needs to be "sourced" from history. This means running through everything that happened up to some point to create a snapshot of the database state (or query).

emccue 5y ago

I think this is true - you will have an easier time not blazing new trails in general - but the need of ledger-like functionality isn't the distinguishing factor. Preserving the history of all changes isn't just for reconstructing that history later, it's a central component in maintaining ACID while allowing for distributed readers. Datomic has a singular transactor - node that can accept writes. So all transactions happen in sequence and consistency is maintained within the data model. So your database goes DB (0 transactions) -> DB' (1 transaction committed) -> DB'' (2 transactions committed) With normal databases, when DB'' is created, DB' is lost. You change stuff in place. This means that anyone wanting to observe a consistent view of the database needs to coordinate with writes. This is why SQL dbs are single giant machines. For Cassandra, Dynamo, Mongo, etc you still change stuff in place, but you just accept that things will be potentially inconsistent ("eventually consistent") for your readers. Once you drop that part of ACID you can scale your readers and your writers arbitrarily. With Datomic DB, DB', and DB'' are still maintained. If you want to read the database "now" you can get a handle to the state that your reader thinks is the most recent. This might not be behind the absolute newest state that the transactor knows about, but it is still a consistent view of the database. Its because of this you can scale your read nodes independently of the system. Because if you are reading DB' you know the value of that won't change you can load chunks of the indexes into the memory for caching and even embed the querying into the application making queries. The proprietary-ness and JVM-ness of Datomic are its biggest weaknesses. I choose to believe those weaknesses can be addressed.

huahaiy 5y ago
Every database that implements MVCC does this, that means most ACID databases. So "reading a consistent view" is not unique for Datomic.
Nihilartikel 5y ago
I'm waiting to have a need to use it, but XTDB is a nice fully open bitemporal 'lite' Datomic that I have been keeping an eye on.
runekaagaard 5y ago
Ah yes, makes me remember the amazing talk by Rich Hickey called "The database as a Value" [1]. I felt like my brain was reorganized after watching it. The simplicity of Datomic is very appealing, it's just a timestamped series of EAV entries, and some fancy indexing. Avoiding the latency (the database over there issue) sounds like a big win. Most of the simplicity is made possible by only having one single synchronous writer which is a major drawback you have to be able to live with. Some write-heavy applications would struggle. Related to the timetravel feature I've bookmarked a blog post by Valentin Waeselynck where he talks about some of the misconceptions and drawbacks. [2]. My company have a not super-great setup with triggers on MySQL, and have longed for MariaDBs SQL 2011 compliant Temporal Tables which looks very interesting [3]. I guess an advantage with Datomic is that you don't have to create an entire table history row when all you want is to update a single field. I was interested enough in Datomic that I started building a Python bridge but never finished it [4]. An added bonus was that I learned about the Transit serialization format which was ALSO super inspiring [5]. [1] https://www.youtube.com/watch?v=D6nYfttnVco [2] https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html [3] https://mariadb.com/resources/blog/temporal-tables-part-1/ [4] https://github.com/runekaagaard/brygge/blob/master/src/jolle/example.py [5] https://cognitect.com/blog/2014/7/22/transit

john567 5y ago

This is true but it's a false premise. You have history but it's clunky to work with. You won't be able to "source" and recreate the past without some work and unexpected things will happen when you "source" the past with the most recent code. It useful but the history aspect is easily misunderstood.

emccue 5y ago
In this respect XTDB has a more directly useful model
blain_the_train 5y ago
Can you explain what "source" means?
- john567 5y ago
  Oh, yeah, think of event sourcing. You have a series of events leading up (aggregate) into some state. This can be done in different ways but with Datomic you can request a point in time database. This database doesn't exist so it needs to be "sourced" from history. This means running through everything that happened up to some point to create a snapshot of the database state (or query).