This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (8)
- # beginners (78)
- # boot (68)
- # cljs-dev (32)
- # cljsrn (43)
- # clojars (2)
- # clojure (147)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-quebec (1)
- # clojure-russia (19)
- # clojure-spec (17)
- # clojure-uk (25)
- # clojurescript (98)
- # clr (2)
- # core-async (14)
- # cursive (5)
- # datascript (1)
- # datomic (23)
- # emacs (4)
- # hoplon (8)
- # jobs (4)
- # kekkonen (1)
- # lein-figwheel (9)
- # off-topic (2)
- # om (2)
- # om-next (9)
- # onyx (4)
- # planck (2)
- # re-frame (14)
- # ring-swagger (3)
- # untangled (18)
@robert-stuttaford I made an edit to your datomic helpers gist https://gist.github.com/robert-stuttaford/39d43c011e498542bcf8
So, what are the disadvantages to using datomic? What are the pain points and how are they managed? What kind of scaling problems does it have? When I attempt to sell datomic to my company, these are questions they will want to hear addressed
the biggest limitation I found was that you can't push down processing to the nodes so with terrascale datasets you have to ship a lot of data. This can be mitigated by denormalizing so you just keep pre-filtered datasets around
Also, can someone give me a link to a primer or a blog post on what the hell impedance mismatch is? This is one of those buzzwords that I keep hearing and only understand inductively
one downside is that you can't use your typical SQL-based analytics tools with datomic; if you're planning to use such tools, you need an etl job that exports data to an SQL database
@tjtolton: when talking about databases, "impedance mismatch" usually refers to the fact that typical SQL + OOP systems have two different ways of representing information: relations (SQL tables) and graphs (objects).
When using a SQL database from an object-oriented language, there's almost always some translation that needs to happen between the database and your code.
As a consequence, you can end up with object-oriented code that breaks some assumptions about how objects should work (such as: calling a
get method should be a fast, efficient operation) and also fails to take advantage of the features of the SQL database (joins, views, optimized queries).
Datomic tries to avoid the impedance mismatch by using a data model (tuples) that has a perfect one-to-one correspondence with regular programming-language data structures (maps and sets). The translation is automatic and loss-less.
On the other hand, this means that applications using Datomic typically stay close to the Datomic data model through much of the application code. It is unusual to wrap "objects" around Datomic transactions or queries, as is commonly done with ORM frameworks in object-oriented languages.
so, the advantages of datomic in a read heavy system seem pretty obvious, because of local querying. Are there advantages to datomic in a write heavy system compared to, say, postgres? one that reacts to n million changes per day?
@tjtolton your transactor limits the write throughput in a way that cannot be scaled horizontally (well, nor can postgres...). In addition, things can get challenging when your datasets get big (the famous "10 billion datoms" limit).
@tjtolton also, re: the impedance mismatch, I recommend this talk: https://www.infoq.com/presentations/Impedance-Mismatch
should you be able to use lookup refs for other entities within the same transaction? from my experiments it seems that’s not possible, and I’m wondering why not.