Hacker News Reader

Comment by lazylland | Hacker News Reader

what's really worrying is that in all this time I've never seen a convincing benchmark, to motivate diving 'head first' into Datomic. For all the hate that the MongoDB guys get, they alteast piqued interest with some arresting charts and figures.

Right now, the impression I get is, "ooh, because Rich Hickey..."

Could anyone share anecdotes to the counter ?

View on HN

I'm self-taught at Relational Database Design. I spent two years worth of about all of my free time learning, and creating, large normalized SQL schemas. One of the things that most struck me was the capacity to get virtually all the advantages of a relational database without the baggage and rigidity. Add to that the fact that you have a distributed database with almost none of the baggage usually associated with such was another big thing for me.

Granted I'm coming from a do-it-myself green-field project, but the things that Datomic's structure and design opens up for my personal project mean that me, a one man show, can far more easily go toe to toe with the big guys with massive teams to design and deploy their apps and databases.

Potential is what I see, and it's far more than I've seen with just about any other technology that I can think of. I really think Datomic is a game changer, at least for the few awake enough to see it.

Datomic is a very cool project, but it's worth being aware that triple stores generally exhibit significantly worse performance than relational DBs for most query workloads. For non-huge projects they're perfectly capable though, and do offer some flexibility benefits.

This is why datomic's query magic is in it's indexes.

Please note that Datomic's architecture is substantially different than most traditional triple stores so I don't think it is useful to extrapolate performance for one from the other.

That's true, and if your workload is such that you're able to predictably query over a relatively small fraction of the database, then I can imagine it working well - it effectively buys you auto-partitioning. If your queries run over a larger subsection of the data, you're still going to run into the fundamental problem of most triple stores: they're join and random i/o heavy. I've not heard that Datomic has anything special going on with regards to this issue, although I may be out of date.

This isn't intended to bag on triple stores - I work on them for a living - or Datomic specifically. Triple stores are very useful and in many ways liberating to work with, but they do present challenges when querying over lots of data.

I'd just eco PureDanger's comment regarding the architecture. I'm no expert on the matter but the concept of having the components of the database taken apart, as they are with Datomic, would give you potential arrangements that you couldn't get with traditional architectures.

I haven't actually used Datomic yet, but what piques my interest isn't necessarily "ooh, Rich Hickey" as much as "ooh, the Clojure/functional approach to data immutability applied to a database". The appeal, to me at least, is in the potential to make my life easier as a product engineer, rather than as a DBA or devops guy.

Very much one of the biggest draws in my opinion, as I've been using Datomic in production for several months. We're a clojure shop and one of the things I've been working on recently is developing a library for parsing/storing/querying all of clojure's data structures into datoms. I hope I get to open source it :)

See "Datomic: Can Simple be also Fast?"(https://news.ycombinator.com/item?id=6426362)

Reply on news.ycombinator.com