[HN Gopher] Max Datom: Interactive Datomic Tutorial
___________________________________________________________________
Max Datom: Interactive Datomic Tutorial
Author : tosh
Score : 56 points
Date : 2022-04-21 09:42 UTC (1 days ago)
(HTM) web link (max-datom.com)
(TXT) w3m dump (max-datom.com)
| icosahedron wrote:
| Can anyone else get beyond the 2nd level? I am getting stuck
| because it returns the values in slightly different order than is
| expected. And I don't see a way to report an issue via the
| website.
| icosahedron wrote:
| I was able to use find the author on the title page, and
| emailed them. I don't know if my query is incorrect or if it's
| a bug.
| cdiamand wrote:
| Fun tutorial! When does it make sense to use Datomic over
| something like MySQL or PostgreSQL?
| alecco wrote:
| Datomic is elegant and it has some interesting properties like
| temporal. This is a huge win for many cases where business
| logic needs them (e.g. finance). I think it would make more
| sense for clients also running JVM. I don't have much
| experience with it but it looks very good. -- a SQL engine dev
| abraxas wrote:
| Mostly when you need a ledger like functionality to your data.
| Datomic preserves the history of all the changes by design so
| it is very easy to reconstruct the history of changes to your
| data.
|
| If this describes the majority of your problem space then
| Datomic is a good fit. Otherwise I would stick to a popular
| RDBMS like Postgres to leverage the community behind it. You
| will have a much easier time interacting with a well understood
| open source engine.
| emccue wrote:
| I think this is _true_ - you will have an easier time not
| blazing new trails in general - but the need of ledger-like
| functionality isn 't the distinguishing factor.
|
| Preserving the history of all changes isn't just for
| reconstructing that history later, it's a central component
| in maintaining ACID while allowing for distributed readers.
|
| Datomic has a singular transactor - node that can accept
| writes. So all transactions happen in sequence and
| consistency is maintained within the data model.
|
| So your database goes
|
| DB (0 transactions) -> DB' (1 transaction committed) -> DB''
| (2 transactions committed)
|
| With normal databases, when DB'' is created, DB' is lost. You
| change stuff in place. This means that anyone wanting to
| observe a consistent view of the database needs to coordinate
| with writes. This is why SQL dbs are single giant machines.
|
| For Cassandra, Dynamo, Mongo, etc you still change stuff in
| place, but you just accept that things will be potentially
| inconsistent ("eventually consistent") for your readers. Once
| you drop that part of ACID you can scale your readers and
| your writers arbitrarily.
|
| With Datomic DB, DB', and DB'' are still maintained. If you
| want to read the database "now" you can get a handle to the
| state that your reader thinks is the most recent. This might
| not be behind the absolute newest state that the transactor
| knows about, but it is still a consistent view of the
| database.
|
| Its because of this you can scale your read nodes
| independently of the system. Because if you are reading DB'
| you know the value of that won't change you can load chunks
| of the indexes into the memory for caching and even embed the
| querying into the application making queries.
|
| The proprietary-ness and JVM-ness of Datomic are its biggest
| weaknesses. I choose to believe those weaknesses can be
| addressed.
| runekaagaard wrote:
| Ah yes, makes me remember the amazing talk by Rich Hickey
| called "The database as a Value" [1]. I felt like my brain
| was reorganized after watching it.
|
| The simplicity of Datomic is very appealing, it's just a
| timestamped series of EAV entries, and some fancy indexing.
| Avoiding the latency (the database over there issue) sounds
| like a big win. Most of the simplicity is made possible by
| only having one single synchronous writer which is a major
| drawback you have to be able to live with. Some write-heavy
| applications would struggle.
|
| Related to the timetravel feature I've bookmarked a blog
| post by Valentin Waeselynck where he talks about some of
| the misconceptions and drawbacks. [2]. My company have a
| not super-great setup with triggers on MySQL, and have
| longed for MariaDBs SQL 2011 compliant Temporal Tables
| which looks very interesting [3]. I guess an advantage with
| Datomic is that you don't have to create an entire table
| history row when all you want is to update a single field.
|
| I was interested enough in Datomic that I started building
| a Python bridge but never finished it [4]. An added bonus
| was that I learned about the Transit serialization format
| which was ALSO super inspiring [5]. [1]
| https://www.youtube.com/watch?v=D6nYfttnVco [2]
| https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-
| this-is-not-the-history-youre-looking-for.html [3]
| https://mariadb.com/resources/blog/temporal-tables-part-1/
| [4] https://github.com/runekaagaard/brygge/blob/master/src/
| jolle/example.py [5]
| https://cognitect.com/blog/2014/7/22/transit
| Nihilartikel wrote:
| I'm waiting to have a need to use it, but XTDB is a nice
| fully open bitemporal 'lite' Datomic that I have been
| keeping an eye on.
| john567 wrote:
| This is true but it's a false premise. You have history but
| it's clunky to work with.
|
| You won't be able to "source" and recreate the past without
| some work and unexpected things will happen when you "source"
| the past with the most recent code.
|
| It useful but the history aspect is easily misunderstood.
| emccue wrote:
| In this respect XTDB has a more directly useful model
| john567 wrote:
| What I've find most useful is the immutable nature of the
| database. That within a reactive framework for UX is great
| combination. You get really cool things to happen with little
| effort.
|
| Also, because the database is a value. You can easily do mock
| data and isolated transactions locally to experiment and test.
| This makes some things easier.
|
| Another cool thing is how you do cross database queries by
| simply passing multiple databases to a function. It will pull
| in the subset of the dataset needed to compute the query
| result. It's that easy to do.
|
| It's not good at dealing with high volume transactions (a lot
| of writes) it's not too bad but it's not built for that
| primarily.
| amelius wrote:
| > What I've find most useful is the immutable nature of the
| database.
|
| Not really a good fit for today's world of privacy
| regulations, where deletion of data should be possible and
| guaranteed.
| lgas wrote:
| Datomic addresses this via Excision.
|
| https://docs.datomic.com/on-prem/reference/excision.html
| deobald wrote:
| XTDB has a simple `evict` operation to resolve precisely
| this issue:
|
| https://docs.xtdb.com/language-reference/datalog-
| transaction...
| emccue wrote:
| As the world stands today, it makes sense to use Datomic if you
| are writing code on the JVM and are willing to pay for the
| database and associated support.
|
| In a hypothetical future world where the data model and query
| approaches have more widespread open source adoption it is
| competitive for a lot of the same use cases.
| casion wrote:
| In addition to what was said, Datomic Cloud automates a lot of
| the annoying and difficult to suss deployment for application
| dev, not just the database. You can deploy large scalable apps
| in minutes and easily deploy new code in minutes with no down
| time (or architecting a deployment system yourself).
| emccue wrote:
| If anyone is interested, I am attempting to revive an open source
| clone of Datomic called EVA.
|
| As is the original codebase works fine, its just unmaintained. My
| hope is to clean up the code, make an HTTP layer for a remote
| peer, and make a Rust embedded peer so that this sort of Database
| can finally escape the JVM.
|
| https://github.com/bowbahdoe/eva
|
| If you want to use something open source today that has the same
| query language but a different data model, https://xtdb.com/ is
| high quality.
| panick21_ wrote:
| Oh really interesting. I didn't know about that. I was actually
| going threw the old Mendat code base and was considering using
| that.
|
| I would really like a pure Rust version of Datomic for embed
| use cases.
|
| There is all also Datahike, that is going in that direction
| too. It is maintained and actively developed.
|
| https://github.com/replikativ/datahike
| emccue wrote:
| Feel free to reach out via any of the contact info on my
| github. The more the merrier chasing this magic dragon.
| den1k wrote:
| if you don't need history, have a look at
| https://github.com/juji-io/datalevin
| emccue wrote:
| Datalevin is good, but its more useful in the same realm as
| sqlite
| layer8 wrote:
| "Your browser is not wide enough to properly render MaxDatom"
|
| Okay.
| LesZedCB wrote:
| its a game kinda thing. it needs rendering space. not mobile
| friendly
| layer8 wrote:
| It would be helpful if they'd say how wide it needs to be
| (landscape didn't help) or that it doesn't work on mobile.
___________________________________________________________________
(page generated 2022-04-22 23:01 UTC)