This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-06-08
Channels
- # admin-announcements (61)
- # beginners (42)
- # boot (16)
- # cider (3)
- # clojure (43)
- # clojure-brasil (6)
- # clojure-france (4)
- # clojure-germany (8)
- # clojure-japan (5)
- # clojure-nl (1)
- # clojure-russia (36)
- # clojure-sg (2)
- # clojurebridge (2)
- # clojurescript (129)
- # datomic (29)
- # editors (42)
- # euroclojure (8)
- # jobs (1)
- # ldnclj (44)
- # off-topic (9)
- # overtone (2)
- # reagent (1)
<!channel> as can be seen in the topic, i’m doing a hangout this friday. if you’re planning to attend, I’ve made a google form with some questions, and i’d appreciate any input you have for me. thanks! https://docs.google.com/forms/d/1opX6Br27woFrJvih4pMPuOpTwlWB4il0EYiHuRwcwYI/viewform
Ouch 1am in NZ
@danielcompton: It will be worth staying up for
@robert-stuttaford looking forward to it
@danielcompton: sorry about that. curse you, solar system!
Hah, and a bunch of us in Bonn/Cologne Germany will be at the ClojureBridge workshop at 5pm. Perhaps we'll come early and watch it on a big screen... 😛
@luke on large strings, would sticking those on their own entities in their own db partition help at all?
thereby containing the slowness to reads of those datoms
… a little
That's getting into implementation details a bit deeper than I know. I don't think putting them on their own entities would make that big of a difference.
ok. part of the problem is that they impact the read-side perf of the rest of the nice, small datoms around them. i thought perhaps if they’re isolated, that might help when using only those small datoms
i guess for it to work you’d have to be careful about when you touch them, which is pretty much the same territory as just using a blob store
it seems logical but someone with a much deeper knowledge of the implementation than I do would need to answer that.
do you perhaps have such a person handy?
thank you! i’d like to make mention of it in that hangout i’m doing on friday. would like to put the partition idea forward, but only if it’s actually a good idea!
@robert-stuttaford: think the blessed story is just to use a squuid pointing at whatever blob store you're using for datomic still though
yeah. it was just an intuition that i thought i’d sanity check. after all, i can actually talk to the people, unlike some other databases i’ve used in the past
@robert-stuttaford: So I forgot momentarily that partitioning is by entity, not by attribute. So you'd have to put all the of the "heavy" attributes on their own entity.
yes. i was aware of that - they’d have to hide behind a ref
At that point it depends on your usage patterns if the extra ref traversal cost outweighs the "heavy" attribute cost.
Probably a benchmark is the only way to tell for sure, absent Rich or Stu themselves weighing in to my question
yes. i guess my question really is, is this a viable strategy for dealing with this tradeoff of Datomic, and if so, when do you know when it’s time to a) use this approach and b) stop using this approach in favour of a blob store instead
again, just a thought experiment; just wondering if this approach would actually help or not
datomic does kinda have some nice properties which are valuable to use even on bigger data -grin-