Cognitect: Relevance merges with Metadata Partners (Datomic)

MrBuddyCasino wrote: post #5

mike_ivanov wrote: post #3

Any plans to opensource Datomic?

What is the big deal about Datomic? From their FAQ: "Datomic is not a good fit if you need unlimited write scalability, or have data with a high update churn rate (e.g. counters)." Don't you get most of that through... caching? Also, it seems to assume that the dataset will fit into RAM.

In short, you can ask a datomic database stuff like "Show me all things that are different for customer X from the database today versus the database one year ago on September 14th at 9:32 AM" and it can answer those types of queries with high performance.

And no, the dataset does not need to fit in RAM.

Re: Cognitect: Relevance merges with Metadata Partners (Datomic)

#7

Post by MrBuddyCasino » Mon, Sep 16, 2013, 3:15 PM UTC

drcode wrote: post #6

MrBuddyCasino wrote: post #5

Earlier quoted context omitted.

What is the big deal about Datomic? From their FAQ: "Datomic is not a good fit if you need unlimited write scalability, or have data with a high update churn rate (e.g. counters)." Don't you get most of that through... caching? Also, it seems to assume that the dataset will fit into RAM.

In short, you can ask a datomic database stuff like "Show me all things that are different for customer X from the database today versus the database one year ago on September 14th at 9:32 AM" and it can answer those types of queries with high performance. And no, the dataset does not need to fit in RAM.

Thanks, that helped. They should be more clear on their website about that, I know Clojure a bit and some of the things about state, time and identity, and I still didn't get it.

Re: Cognitect: Relevance merges with Metadata Partners (Datomic)

#8

Post by grayrest » Mon, Sep 16, 2013, 3:34 PM UTC

MrBuddyCasino wrote: post #5

mike_ivanov wrote: post #3

Any plans to opensource Datomic?

What is the big deal about Datomic? From their FAQ: "Datomic is not a good fit if you need unlimited write scalability, or have data with a high update churn rate (e.g. counters)." Don't you get most of that through... caching? Also, it seems to assume that the dataset will fit into RAM.

Datomic is interesting because it's a different take on what a database should look like. The TLDR version by someone who's looked into it a bit but not actually used it:

* Storage, Transactions, and Querying are separated as in different processes/machines separated.

* Data is immutable. Storage is pluggable and has implementations on top of Dynamo/Riak.

* Transaction semantics and ordering are controlled by a single process for consistency. This is the write scaling caveat. It's less of a restriction than it sounds (if you're thinking SQLite2 like I did) because there aren't writes/queries competing for resources, it's just the sequencing.

* Queries on the db are performed in-client and can interoperate with client code and state. When you write a query, datomic pulls the data from storage to the local machine and performs the query.

* Queries are in a logic programming language called datalog. Even if you aren't interested in the rest, I'll recommend spending an hour working through http://learndatalogtoday.org/ just for the exposure to logic programming.

Re: Cognitect: Relevance merges with Metadata Partners (Datomic)

#9

Post by bfe » Mon, Sep 16, 2013, 4:00 PM UTC

((defn cognitect ([] (conj [relevance] datomic)))) ; => all ur cljr r belong to us

Re: Cognitect: Relevance merges with Metadata Partners (Datomic)

#10

Post by zerr » Mon, Sep 16, 2013, 4:01 PM UTC

grayrest wrote: post #8

MrBuddyCasino wrote: post #5

Earlier quoted context omitted.

What is the big deal about Datomic? From their FAQ: "Datomic is not a good fit if you need unlimited write scalability, or have data with a high update churn rate (e.g. counters)." Don't you get most of that through... caching? Also, it seems to assume that the dataset will fit into RAM.

Datomic is interesting because it's a different take on what a database should look like. The TLDR version by someone who's looked into it a bit but not actually used it: * Storage, Transactions, and Querying are separated as in different processes/machines separated. * Data is immutable. Storage is pluggable and has implementations on top of Dynamo/Riak. * Transaction semantics and ordering are controlled by a singl…

You mean the whole data is fetched to the client and only queried afterwards? Why did they choose this way?