Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rich Hickey's new project: datomic.com

datomic.com

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Rich Hickey's new project: datomic.com

#31

Post by stevelosh »

psykotic wrote: post #25
puredanger wrote: post #24

Earlier quoted context omitted.

When data is immutable, append-only, and tagged by timestamp, there is no conflict. Rather, there are facts on the same entity that are asserted at different times. In this case where changes come in at two times (which are subject to all the raciness of the real world that exists regardless), one will win.

> In this case where changes come in at two times (which are subject to all the raciness of the real world that exists regardless), one will win. That describes many methods of optimistic concurrency control, but it doesn't answer my question of how this supposed to work in practice with high write contention, the higher latency of a distributed peer model, the long-running transactions the video mentions (or maybe t…

From the FAQ:

    Thus, Datomic is well suited for applications that require write consistency and read scalability.
Seems like they're not focusing on high-write situations.

Re: Rich Hickey's new project: datomic.com

#32

Post by swalsh »

Clojure is an amazing language, so i'm willing to go the extra mile to attempt to understand this work. However there's one thing that I can't get over. From my understanding, the big idea is the query engine is brought local, and the storage would eventually come local too. It seems like for smallish db's this is fine. What happens though if you're working with a rather large database?

Additionally, If local means the users client, how is security of the data ensured?

Re: Rich Hickey's new project: datomic.com

#35

Post by spullara »

breckinloggins wrote: post #3

It looks like a very cool product/service, but there's something... off... about this landing page. I can't quite put my finger on it. Two things I can think of right off the bat: 1. The use of the term "whitepaper". It's very "enterprisey" 2. It took me a bit of perusing to figure out what the product IS. I think the lead paragraph may need some tweaking In all, the landing page makes the product feel intimidating.…

If I got one thing out of this article, it is your comment and link to Parse. That looks pretty nice! The landing page for datomic is horrible and I didn't make it past the small, dense text.

Re: Rich Hickey's new project: datomic.com

#36

Post by nickik »

swalsh wrote: post #32

Clojure is an amazing language, so i'm willing to go the extra mile to attempt to understand this work. However there's one thing that I can't get over. From my understanding, the big idea is the query engine is brought local, and the storage would eventually come local too. It seems like for smallish db's this is fine. What happens though if you're working with a rather large database? Additionally, If local means t…

What does this have to do with clojure? This system could have been build in any language, clojure only uses some of the same ideas (working with values). I cant help you with your question, sorry.

Re: Rich Hickey's new project: datomic.com

#38

Post by lukev »

jasonkolb wrote: post #10

I have to admit I'm a little confused about what this is. I'm taking a coffee break and not really into reading a whitepaper, so take that with a grain of salt, but I'd call that a landing page failure. That said, it sounds like a database-as-a-service? If so, is the primary benefit the reduced database management load? Or is there some special sauce in here that makes it more capable than other RDMS or NoSQL databas…

It's a database, quite different from any that are currently out there (you should read the white paper). Although one of the initial pricing models is to sell it as a cloud based service, that's incidental to the technology and why it's cool.

Re: Rich Hickey's new project: datomic.com

#39

Post by edwardw »

stevelosh wrote: post #31
psykotic wrote: post #25

Earlier quoted context omitted.

> In this case where changes come in at two times (which are subject to all the raciness of the real world that exists regardless), one will win. That describes many methods of optimistic concurrency control, but it doesn't answer my question of how this supposed to work in practice with high write contention, the higher latency of a distributed peer model, the long-running transactions the video mentions (or maybe t…

From the FAQ: Thus, Datomic is well suited for applications that require write consistency and read scalability. Seems like they're not focusing on high-write situations.

I noticed that in FAQ, too. Since read is relatively easy to scale (simple master / slave setup), I wonder how to scale datomic on write side.

Re: Rich Hickey's new project: datomic.com

#40

Post by drcode »

swalsh wrote: post #32

Clojure is an amazing language, so i'm willing to go the extra mile to attempt to understand this work. However there's one thing that I can't get over. From my understanding, the big idea is the query engine is brought local, and the storage would eventually come local too. It seems like for smallish db's this is fine. What happens though if you're working with a rather large database? Additionally, If local means t…

Not the _entire_ database is moved locally, only enough to efficiently handle the queries of interest. (i.e. queries run against a dynamic local cache of the database)
Post reply on HN