81–90 of 111 posts
Earlier quoted context omitted.
This is really cool. Highly recommended. You see some querycode in clojure and in java.
I'd say all the query code is written in Clojure, but if you insist on using Java, you can put the queries inside Java strings.
Earlier quoted context omitted.
> I'd like to know how its model of transaction isolation works given that reads and writes are claimed to be independent. Any MVCC-style model allows full concurrency between readers and writers. The bigger problem is managing concurrency between conflicting writers in what amounts to a distributed database system. None of the material on Datomic's website explains how they intend to tackle that issue, which seems e…
The FAQ says that writes favour consistency over availability, so I guess that means synchronous calls to the transactor.
Update:
1. you can do synchronous transactions.
http://datomic.com/docs/javadoc/datomic/Connection.html#tran...
2. transactions can include data functions.
"The database can be extended with data functions that expand into other data functions, or eventually bottom out as assertions and retractions. A set of assertions/ retractions/functions, represented as data structures, is sent to the transactor as a transaction, and either succeeds or fails all together, as one would expect."
Earlier quoted context omitted.
I'm pretty sure the whole thing is built on the JVM, but I agree with you that having a peer run inside a js browser app via clojurescript would be a logical next step. (and arguably really useful)
From FAQ: Is Datomic just for JVM languages? At the moment, yes. We have ideas for how to enable Datomic on non-JVM languages while preserving as much of the embedded power as possible.
However, my big concern here would be security. You'd need to be able to supply a predicate for which datums are allowed to be synced to the client.
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…
So if such a highly distributed system was to use Datomic, it would be harder to guarantee that each peer can work both for reads & (local) writes while being partitioned from the transactor. One would need to program the software to log those new facts (writes) locally before submitting (syncing) them to the transactor. And make that durable. Also, one might also need to make the query/read cache durable, since there's no network to fetch it back in case of a reboot of the peer. So it seems there's a missing local middleman/proxy that needs to be implemented to support such scenarios. At least, thanks to Datalog, the local cache would still be able to be used with this log, using db.with(log).
What do you think, is this use case quite simply implementable over/with Datomic, without asking it to do something out of its leagues?
Some differences: 1. No concept of inference/reasoning 2. No mention of a graph 3. Interesting use of clientside caching / data-peering 4. Clojure serialization vs N3/Turtle/RDF
Some similarities: 1. Quadstores have are parameterized by graph, Datomic by time 2. subject-predicate-object model 3. query-anything ( including [ ?s ?p ?o] ??) 4. query anywhere (sending an rdf to a client for local query seems similar)
edit- I give up trying to get HN to render an ordered list. Any help would be... helpful.
Earlier quoted context omitted.
> a time (denoted by the transaction number that added it the database). Do transaction numbers have total order or just partial order? Total order is serializing. (And no, using real time as the transaction number doesn't help because it's impossible to keep an interesting number of servers time-synched.) Partial order is "interesting".
It is totally ordered. The transactor is a single point of failure. However, since its only job is doing the transactions, the idea is it can be faster than a database server that does both the transactions and the queries.
Earlier quoted context omitted.
> a time (denoted by the transaction number that added it the database). Do transaction numbers have total order or just partial order? Total order is serializing. (And no, using real time as the transaction number doesn't help because it's impossible to keep an interesting number of servers time-synched.) Partial order is "interesting".
It is totally ordered. The transactor is a single point of failure. However, since its only job is doing the transactions, the idea is it can be faster than a database server that does both the transactions and the queries.
Huh? How is that consistent with:
> access the data storage through a new distributed component called a transactor.
If "doing the transactions" consists of more than passing out incrementing transaction tokens, won't the transactor be a bottleneck?
Earlier quoted context omitted.
It is totally ordered. The transactor is a single point of failure. However, since its only job is doing the transactions, the idea is it can be faster than a database server that does both the transactions and the queries.
> However, since [the transactor's] only job is doing the transactions Huh? How is that consistent with: > access the data storage through a new distributed component called a transactor. If "doing the transactions" consists of more than passing out incrementing transaction tokens, won't the transactor be a bottleneck?
The transactor is involved in just writes, not reads. (So that helps.) It's not distributed and cannot be distributed, in this system, because it ensures consistency, so yes, it is potentially a bottleneck. In blog comments by Rich Hickey[1], he states:
"Writes can’t be distributed, and that is one of the many tradeoffs that preclude the possibility of any universal data solution. The idea is that, by stripping out all the other work normally done by the server (queries, reads, locking, disk sync), many workloads will be supported by this configuration. We don’t target the highest write volumes, as those workloads require different tradeoffs."
Presumably, 1) the creators of Datomic think that performance can be good enough to be useful, 2) this is a new model that probably requires testing to prove is practical.
[1] Multiple people have linked to it, but for convenience: http://blog.fogus.me/2012/03/05/datomic/comment-page-1/#comm...