No video :(

KotlinConf 2018 - Datomic: The Most Innovative DB You've Never Heard Of by August Lilleaas

Подписаться 202 тыс.

Просмотров 14 тыс.

50% 1

Recording brought to you by American Express americanexpres...
Datomic is a strange database. The writer is single threaded. It writes to other databases and has no storage of its own. It has a completely different API for reads and writes. Queries runs on the client, not the server. Time travel is built in, and you can query the history of your database.
In this talk, you'll learn where Datomic fits and for which use cases the above are good ideas, how Datomic actually invented very little and stands on the shoulders of BigTable and VoltDB, all using Kotlin, of course :)
About August Lilleaas:
A full stack software developer, working as a consultant in Oslo. Builds CRUD for clients, with SQL databases, Datomic, JVMs, Clojure, Groovy, React and React Native.

Опубликовано:

29 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 16

@kahnfatman 2 месяца назад

Let's rebuild Datomic in Haskell!

@mikl2345 4 года назад

Nice talk, August! I've watched all of Rich Hickey's talks on Datomic, and have begun using it, yet it was here the penny finally dropped for me on how Datomic can keep code functional - a particular database value never changes, so, given such a value, code using said value remains functional. Of course, the database value does change over time (though as we say in Clojure, the identity doesn't). I suppose, then, with the database as a succession of values over time, 'functional' code in relation to the database as an identity just needs to specify a 'basis', as Rich says. Wondering in what senses this makes our whole system "completely functional"? (theoretically speaking? practically speaking?). It was the part where you used the term "time travel" to refer to the previously held values of (d/db conn), rather than a history value, which made me notice that. I'd mainly thought of "time travel" as being something associated with using a history value, but, of course, it can also mean holding on to a specific basis. Thanks for the nice talk!

@boerre9000 2 года назад

Hi! I think it's more correct to say that Datomic enables the "functional core, imperative shell" pattern for the database. Normally, the database is completely imperative. But with Datomic, you're able to do queries against an immutable value. And transactions are different too. They're not "opened" with imperative back and forth. You pass a finished data structure representing the transaction to Datomic. So, your imperative shell can ask for the latest db, and the functional core can query functionally on that. And your imperative shell can ask the functional core to decide on what transaction to run, in a completely functional way, and then pass that on imperatively. So the imperative shell is super super thin when you use this pattern with Datomic. I hope that clarified it :)

@ivanbulanov5754 3 года назад

Everything said about performance is without any proof because Datomic TOS prohibits publishing of any benchmarks. It may support 1M QPS or it may just do a 100. You will never find out until you waste time benchmarking it yourself.

@alexandrkondratyev5379 2 года назад

Isn't it the same at Oracle? for example

@diegonayalazo 2 года назад

Thanks for sharing

@David-iq1kd Год назад

How would you compare / choose between Datomic and XTDB?

@odiexx 5 лет назад

25:33 Except there is, as the transactor needs to broadcast the latest transaction to all connected peers. At what point does resource limitation of the client come into play, particularly at scale?

@softwarestory 5 лет назад

I've seen it scale to hundreds of machines with no discernible impact on writes. I have a feeling notifications are asynchronous, don't block writes, and don't block notifications to other peers. I'm unable to find any official documentation on this, but that was pretty much my experience.

@boerre9000 4 года назад

Oh hey, comments! The transactor only has to tell the peers about the pointer to the new «head» of the index tree slash tx log. And the peer will talk directly to storage (i.e postgres, dynamo, ...) to fetch data. You can even put memcached between peer and storage to speed things up.