This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-03-27
Channels
- # aleph (5)
- # announcements (18)
- # beginners (200)
- # cider (25)
- # cljdoc (4)
- # cljsrn (3)
- # clojure (90)
- # clojure-europe (3)
- # clojure-finland (5)
- # clojure-france (1)
- # clojure-houston (1)
- # clojure-italy (8)
- # clojure-nl (15)
- # clojure-spec (24)
- # clojure-uk (20)
- # clojurescript (199)
- # core-async (2)
- # cursive (45)
- # data-science (14)
- # datomic (33)
- # duct (13)
- # fulcro (4)
- # graphql (3)
- # kaocha (9)
- # leiningen (24)
- # nrepl (16)
- # off-topic (105)
- # pathom (15)
- # pedestal (28)
- # re-frame (1)
- # reagent (14)
- # shadow-cljs (28)
- # spacemacs (8)
- # tools-deps (8)
- # vim (4)
if in a domain every single event is timestamped (time being the integral part of every 'entity'), then is there a point in the database itself keeping a record of 'transaction history'?"
You have multiple time models, wall clock time, and logical time. Think of it as 2 axis on a graph.
If you don’t have a logical clock time you could never learn anything new about something in the past or correct any information.
That being said, datomic is a good fit for your transactional database, not as great a fit in the time-series analytics department when you have tons of datoms.
does the fact that datoms are timeless in general, make the order of transactions dependent on the local ordering of a particular datomic instance? what if two datomic instances receive those datoms in different orders?
@veix.q5 Datoms are not "timeless". Each datom points to the transaction that asserted it. The order of datoms in a transaction does not matter. Transactions are atomic.
And there is only one "datomic instance", one transactor processing transactions serially.
The authors of Datomic made the explicit tradeoff of not making it write-scalable, and for many, many use cases that's fine. Systems tend to read much more than they write, and to give more importance to consistency than write throughput. Another DB making this tradeoff is VoltDB. Consider than, in typical RDBMS such as PostgreSQL, reads slow down writes (due to locking, required by mutability), making the typical OLTP workload even less scalable.
If you eventually outgrow a single transactor, one thing you can do is split into multiple databases, each running their own transactor. On the read side, you can query across multiple databases (with on-prem only, Cloud doesn’t support this). The video below discusses how the Nubank guys designed their system with the anticipation of eventually splitting into multiple databases. https://youtu.be/7lm3K8zVOdY
@U0JPBB10W interesting, thanks!
@veix.q5 What joe said + a transaction is a collection of datoms https://docs.datomic.com/cloud/whatis/data-model.html#datoms
thanks for clearing this up, so a bunch of datoms are tied together in a transaction and datomic itself is the total ordering of those txs. right?
you can store a time value in the commit itself, but that is saying something different from the metadata about the commit itself
(this analogy breaks down a bit because datomic datoms all occupy the same data space, vs git where there's source and then another layer on top of it)
but generally everything you would use git for on your source you would use transaction metadata and the time features of databases (d/history, d/as-of d/since) on your data
This is an excellent guide to datomic's internals: https://tonsky.me/blog/unofficial-guide-to-datomic-internals/
And this is an excellent article explaining why you usually can't use transaction time as the only time in your data (or vice-versa) and why datomic is not a great fit for time-series data: https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html
The find-coll specification is not supported in the cloud version (yet?)
Hi all, I have a datomic on-prem transactor deployed via cloudformation (as per the docs) and I'm looking into how to add classpath functions. Any advice or pointers to documentation?
The main docs are here: https://docs.datomic.com/on-prem/database-functions.html
Any chance the correct solution for the problem at https://forum.datomic.com/t/dependency-conflict-with-ring-jetty/447/7 could be added to the Datomic Cloud docs? It didn't even cross my mind that there might be a conflict between these, and my normal workflow would be to check the dependencies or issues on github which doesn't really work here.