Introduction to datomic
2 likes1,089 views
The document introduces Datomic, an immutable database with an architecture that separates reads, writes, and storage. It has several key benefits, including built-in data distribution and caching, elastic scaling, and a data model based on immutable facts rather than embedded structures. The programming model uses a peer embedded in applications to pull indexed data as needed, and supports transactional updates and time-based queries using a declarative Datalog language.
![transactions
[:db/add entity-id attribute value]
[:db/retract entity-id attribute value]
{:db/id entity-id!
attribute value!
attribute value!
... }
[:db.fn/retractEntity entity-id]](https://image.slidesharecdn.com/introtodatomic-140715111954-phpapp02/85/Introduction-to-datomic-34-320.jpg)
![queries
[:find ?e :in $ ?email !
:where !
[?e :person/email ?email]]
[:find variables :where clauses]
[:find ?e ?x !
:where !
[?e :age 42] [?e :likes ?x]]](https://image.slidesharecdn.com/introtodatomic-140715111954-phpapp02/85/Introduction-to-datomic-36-320.jpg)
Introduction to datomic
- 1. Introduction to Datomic Siva Jagadeesan
- 2. “there’s an another database!” • what do you think of first?
- 3. The job of a database •Coordination •Consistency •Indexing •Storage •Queries
- 5. • Place-oriented-programming (PLOP) • designed decades ago • tiny RAM, tiny disks • Collocated components • Difficult to scale • Necessitates application-level sharding The dreaded update-in-place
- 6. sharding • lose • consistency • transactions • queries
- 7. key-value stores • lose • querying • really just storage systems • not “databases”
- 8. Deconstruction • relocate subsystems • separate services each do one thing • simplification
- 9. Datomic architecture • Peers • Transactors • Storage services
- 10. The new world
- 11. Benefits • Separating reads and writes • applications only read from storage • transactor • handles transactions • provides consistency • reflects changes to peers
- 12. Benefits • Integrated data distribution • built-in in-memory caches • self-tunes to working set • automatic
- 13. Benefits • Peers each have a query engine • Datalog • simple rules and data patterns • declarative: implicit joins • declarative: meaning is evident • locality: datomic db and app data
- 14. Benefits • Elasticity • as elastic as peers
- 15. Benefits • Cloud ready • commodity hardware • resilient to failures
- 16. Data model • Immutable data • remember everything • things don’t actually “change” • audit everything • automatic
- 17. Data model • Facts-oriented (vs. PLOP) • Atomic Data • datoms • entity, attribute, value, transaction • Not embedded into strucures
- 18. Data model • Minimal Schema • at the datom level • directly supports cardinality • avoid rigidity • even other “schema-free” documents impose their structure into apps • Hickey:“nothing pivots like a datom”
- 19. Programming model • Peer embedded in your application • Pulls indexes or data segments as needed • Caches locally, gets updates from transactor
- 20. Programming model • No strings-based query language • Data-structure-driven • Lists and maps • Easy to generate and test
- 21. Programming model • Transactional • Totally ordered • First class: peers get a queue of all transactions • Can use them in queries • Facilitates event-driven triggers without polling • Annotated transactions
- 22. Programming model • Datalog • deductive query system • facts = datomic db • can also include other app data • extensible through custom functions that queries can use
- 23. Programming model • Consistent • without impeding other threads or peers • reads/queries without transactions • through immutability • db as a value
- 24. Programming model • Time • as-of queries • windowed queries
- 25. The so-what • Simplicity • consistency • built-in caching • no manual sharding • configuration-free • cloud-scale
- 26. The so-what • Evolvability • datom-level schema • application free to change “structural” thinking
- 27. The so-what • Local query power • each peer has full query engine • the db is effectively local • isolation from others: • e.g. - analytics usage won’t bog down transaction processing
- 28. The so-what • Multiple storage choices • in-memory for developing, unit-testing • RDBMS backend possible (behind firewall, etc) • Distributed storage services for redundancy and unlimited read scaling • backup/restore tools available
- 29. The so-what • Integrated mem-cache support • local caches can be backed by OTS mem- cache cluster • datomic is a “good citizen” user
- 30. The so-what • Leverage datalog against multiple sources • datomic db • application data
- 31. The so-what • Travel through time • audits • bug-resolution
- 32. Schema def {:db/id {:part :db.part/db, :idx -1000001}, :db/ident :user/login, :db/valueType :db.type/string, :db/cardinality :db.cardinality/one, :db/fulltext true, :db/doc "the login handle of a user", :db.install/_attribute :db.part/db}
- 33. Schema def {:db/id {:part :db.part/db, :idx -1000003}, :db/ident :user/friends, :db/valueType :db.type/ref, :db/cardinality :db.cardinality/many, :db/fulltext false, :db/doc "the friends of a user", :db.install/_attribute :db.part/db}
- 34. transactions [:db/add entity-id attribute value] [:db/retract entity-id attribute value] {:db/id entity-id! attribute value! attribute value! ... } [:db.fn/retractEntity entity-id]
- 35. identities {:part :db.part/user, :idx -1000026} {:db/id 17592186045420}
- 36. queries [:find ?e :in $ ?email ! :where ! [?e :person/email ?email]] [:find variables :where clauses] [:find ?e ?x ! :where ! [?e :age 42] [?e :likes ?x]]
- 37. queries • lots more • pattern matching • logic programming • multiple data-sources
- 38. demonic • datomic helper • work at the data-structure level • supports graphs: nested maps • only writes dirty data • “demarcations” as “batched datomic transactions” • unit-testing support
- 39. Questions