Fork me on GitHub
#off-topic
<
2019-04-01
>
dpsutton01:04:46

interesting, The Joy of Clojure is on audible as an audiobook ....

😂 4
dominicm08:04:02

"Open paren defun buy dash book"

😂 8
3Jane09:04:55

oooh so that’s why it’s called “the joy of clojure”

3Jane09:04:08

“do fun, do fun, do fun”… but that’s not good English, is it.

dominicm08:04:37

(In bold because the reader is shouting to indicate the exclamation mark suffix)

quadron14:04:19

does anyone have a recommendation for a simple embeddable keyvalue database? i am leaning towards lmdb, but was wondering if there is a de facto standard clojure community uses?

orestis14:04:30

How much data do you want to store? Is it in-memory or should also be persisted to disk? How do you expect to query it? I think you will get much better recommendations if you can narrow down your requirements a bit 😉

quadron14:04:48

data is market trade events. it is supposed to persist to disk and used for data analytics research and also fed to trading bots. I don't worry about the rate of incoming data being too high at the moment, simplicity and ease of use, availability of libs has more value to me.

adamfeldman14:04:14

https://github.com/replikativ/datahike looks interesting but I haven't yet started working with it

❤️ 8
adamfeldman14:04:19

But given you're dealing with trade events. maybe a time-series database would be best? https://www.timescale.com (Postgres extension)

mpenet14:04:36

you could something like chronicle-queue to persist the stream of trade events to disk and replay it on whatever app/storage you want to use later

mpenet14:04:11

buys you some (relative) safety when it comes to rate of incoming data too

mpenet14:04:44

it's also super easy to get started, since it's essentially embeddedable.

✔️ 4
💡 4
quadron14:04:39

chronicle-queue seems to fit in nicely, thx