Fork me on GitHub
#datomic
<
2019-01-20
>
okocim23:01:29

I don’t quite understand the tradeoffs between creating enumerations as :db/idents then accessing them as attribute-refs vs. creating attributes of :db.valueType/keyword. I a blanket statement in the docs to model enumerations as refs (i.e. the first way I’m talking about), but I don’t really understand any tradeoffs that this might create. I was wondering if anyone might know when using idents would be better than using keywords or vice-versa. Or, if someone could point me at some further reading. At the end of the day, I’ll stick to the published advice, but I’d like to be able to reason more about my schema choices. Typical of enumerations, these are low-cardinality attributes that will be on many, many entities.

johnj22:01:53

Datomic is a slow DB use mostly for low load internal apps, using ident for enums improves performance by the way of reducing memory and storage use.

okocim22:01:00

Thanks for the reading material. The discussion makes sense. I didn't notice any appreciable difference in perf between the two approaches (take that with a grain of salt, it was for my specific use case), so I ended up going with the keywords because I plan on adding more values in the future, and don't see the need to require a schema change to do so in my case. Still, I do appreciate the help that folks have given me to gain better understanding.

tim22:01:32

> using ident for enums improves performance by the way of reducing memory and storage use. I don’t see how. Idents still store dbids per entry.

tim23:01:32

Yeah I read that, but how is storing a keyword any different memory wise than storing a pointer? you still have to store something per entry. That was the question I was posing in the original post, but no one from the datomic team bothered to respond.

tim23:01:01

@U4R5K5M0A it’s probably worth reading the last post by anton here: https://groups.google.com/forum/#!topic/datomic/KI-kbOsQQbU

johnj23:01:10

fair, this needs more info from them

johnj23:01:23

I don't think they answer stuff like this in detail to encourage users to buy support.

johnj23:01:36

from what I have seen

marshall14:01:17

all idents are stored in memory

marshall14:01:59

in particular

marshall14:01:01

“Idents are designed to be extremely fast and always available. All idents associated with a database are stored in memory in every Datomic transactor and peer. ”

marshall14:01:28

if you’re using Cloud, all nodes in your compute groups and query groups (instead of transactor and peer)

tim16:01:14

@U05120CBV fair enough. I’m not sure how different it would be performance wise when you consider the jvm hotspot internals against cached data. I think it’s fair to say enums are optimal, but the question was really how much so… if it’s a nominal difference then enums don’t look too good when they require schema changes for additions and lack cardinality support.

marshall16:01:55

there are tradeoffs of both approaches; i suspect the perf difference is quite minimal; sometimes it’s nice to have your “enumerated options” live in the same place as your data model definitions (schema); sometimes it’s nice to be able to build up more complex data structures around/about your enums (i.e. more attrs on them); on the flip side, not dealing with refs can be more straightforward (i.e. just have a kw value)