This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-17
Channels
- # adventofcode (76)
- # announcements (6)
- # beginners (103)
- # boot (28)
- # calva (128)
- # cider (48)
- # cljs-dev (40)
- # clojure (268)
- # clojure-austin (2)
- # clojure-dev (2)
- # clojure-europe (47)
- # clojure-italy (10)
- # clojure-nl (17)
- # clojure-spec (2)
- # clojure-uk (15)
- # clojurescript (45)
- # code-reviews (14)
- # cursive (5)
- # data-science (2)
- # datascript (1)
- # datomic (52)
- # duct (4)
- # emacs (2)
- # figwheel (1)
- # figwheel-main (4)
- # fulcro (13)
- # hyperfiddle (51)
- # leiningen (19)
- # nrepl (40)
- # off-topic (45)
- # pathom (3)
- # pedestal (28)
- # portkey (7)
- # re-frame (25)
- # reagent (76)
- # reitit (7)
- # shadow-cljs (92)
- # slack-help (3)
- # specter (5)
- # timbre (2)
- # tools-deps (39)
- # unrepl (1)
- # vim (13)
@viesti > data+compute locality is a good thing I think, avoids shuffling of data. don’t forget the fineprint: • when data is easily shardable (no broad join required) • when you have a good enough idea of data distribution to have balanced shards.
this paper spawned discussion elsewhere too, I skimmed (I have to learn to read papers too, instead of skimming :)) the Pywren paper and was thinking that in what they did, data placement in S3 was a good git for Lambda autoscaling
Could this be done with a more data-centric approach: https://aws.amazon.com/blogs/aws/boost-your-infrastruc