The document discusses problems with traditional mutable databases like losing history data when records are updated and the inability to retrieve past states. It introduces Datomic as an immutable database that can retrieve past states using its "as-of" operator similar to a git checkout. It also explains that Datomic improves scalability by running queries on clients instead of the server and uses transactions through data forms instead of SQL to prevent injection attacks. Workarounds without Datomic include using as-of in SQL 2011, Kafka with CQRS/event sourcing, or wrapping SQL in APIs. Overall, Datomic provides lessons on separating reaction from perception and solving impedance mismatch through an alternative approach of decomposing databases.

1. Immutable database
- Datomic
Laurence Chen
twitter:humorless
https://replware.dev

2. Agenda
● History problem
● Scalability problem
● String interpolation problem
● Three solutions from Datomic
● Workarounds if you can not use Datomic
● What can we learn from Datomic

3. History problem - part 1
Below was the state of your table yesterday.
Yesterday, you sold 60 apples and 40 oranges.
Product_ID Product_Name Quantity
1 Apple 100
2 Orange 200

4. History problem - part 2
Now, can you get the quantity about your product
yesterday? You can not.
Product_ID Product_Name Quantity
1 Apple 40
2 Orange 160

5. How to deal with this problems?
● Design product table and product history table.
● Backup your database every certain time span, and
then you can get the history state of your database.
● Change RDBMS to Datomic, and you can get as-of
operator. `(as-of db tx)` is just like `git checkout
[revision] .`

6. The immutable database --- Datomic

7. Scalability problem
● Traditional multithreaded databases only spend about
25% of their time actually writing to and reading from
the database.
● The rest of the time is spent coordinating multiple
clients reading and writing in parallel.
● CAP theorem

8. Lambda Architecture

9. Kappa Architecture

10. Traditioanl RDBMS
architecture

11. Datomic Architecture

12. String interpolation problem
Application Program
Databse
Server
Query
Template
“select * from XXX;”

13. String interpolation - SQL injection example
● “ SELECT x, y, z FROM Table WHERE id = ‘$id’; “
● If $id is replaced with
○ “ ‘; DELETE FROM Table; SELECT * FROM Table
WHERE id =’ ”

14. Datomic transaction
Application program
Transactor Process

15. Datomic transaction - Code Snippet
● (d/transact conn [[:db/retract entity-id attribute
value]])
○ the green color part is data form.

16. Datomic query
Application program
Database as value
Sync with transactor

17. Three solutions from Datomic
1. as-of
2. Run queries on the client, not on the server.
3. Transaction & Query through only data.

18. Workarounds if you can not use Datomic
● as-of (SQL 2011)
● Kafka (unbundled database) + CQRS + event sourcing
● Use API to wrap SQL statement/query.
○ The API should use an appropriate set of data
structures instead of textual language.

20. What can we learn from Datomic?
● Separation of reaction and perception.
● Solve impedance-mismatch problem from different
route:
○ ORM wraps the SQL interface.
○ Datomic decomposes the database.

21. Q & A