This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-10
Channels
- # aleph (1)
- # announcements (21)
- # babashka (3)
- # beginners (98)
- # calva (2)
- # circleci (3)
- # clara (58)
- # clj-kondo (123)
- # cljs-dev (1)
- # cljsrn (7)
- # clojure (162)
- # clojure-europe (2)
- # clojure-finland (7)
- # clojure-italy (5)
- # clojure-nl (6)
- # clojure-sanfrancisco (1)
- # clojure-spec (1)
- # clojure-survey (17)
- # clojure-uk (70)
- # clojuredesign-podcast (2)
- # clojurescript (46)
- # cloverage (5)
- # cursive (2)
- # data-science (22)
- # datascript (1)
- # datomic (60)
- # emacs (3)
- # figwheel-main (1)
- # fulcro (26)
- # graalvm (5)
- # jackdaw (3)
- # leiningen (8)
- # luminus (1)
- # off-topic (8)
- # other-lisps (2)
- # pedestal (27)
- # re-frame (17)
- # reagent (20)
- # reitit (3)
- # shadow-cljs (37)
- # spacemacs (23)
- # sql (69)
- # tools-deps (2)
- # utah-clojurians (9)
- # xtdb (3)
Uh-oh... đ
I'm having an internal debate whether to use PostgreSQL (which is my fave database of all time - well, except the one I wrote back when I were a kid, ran on BBC Basic and provided you were storing records (as in vinyl), with a name, duration and rating - and do not dare to deviate from norms), or use Elasticsearch.....
Funnily enough, I wrote my own database, back in the day, for managing my record collection too!
But it was UCSD Pascal on a SAGE IV.
It turned out very useful when I was burgled: I was able to give the insurance company an itemized list of every CD stolen, date purchased, price paid, shop bought from. So they treated it as a per-item claim -- and opened an account at HMV London for me with ten thousand pounds credit đ
Yeah, in two visits. About 8k the first time and 2k the second. They treated me like royalty đ
I had about 2,000 CDs. The burglars took about half the collection đ
I left most of the CDs behind in England -- brought only a few hundred over, twenty years ago -- but I've re-purchased a lot of it on iTunes since. I have over 60GB of music now I think...
iTunes says I have 960 albums by 455 artists. 8,752 tracks.
The use cases are the same, storing data, in both cases JSON (with additional fields)
Chalk and cheese.
I'm very used to postgres, the libraries (thanks sean!) are great and blend lovely with Clojure. The thing that the user only wants to do is lookup data using an id - there isn't yet and I say yet any need for full text searching.
I presently use Elasticsearch, but now I have a requirement from the users to add notes to the data
and for that, having a little table with a simple straight-forward join to the parent is suuupar simple with PG (or any db)
We use both MySQL and Elastic Search at work. MySQL for structured, relational data. ES for less structured, searchable with complex, scored queries.
We don't do much text searching but we do geo searches, age range searches, etc.
The ability for pg to index on json data (and store it efficiently as jsonb) - also to search inside json has come a long way
and I choose ES originally as the json stored in ES would be (currently is!) immutable
We post updated profile data to ES regularly -- every time a member changes their profile. We don't view ES as immutable.
If they create data around fraud, they want that data not be changeable, since it could be used as part of an official investigation, so they need to know the state of the world at that precise point in time.
I know I may sound biased here, but it might be worth looking at Crux
Reason being your need for point in time queries. The bitemporality feature of Crux is probably perfectly suited for what you need here
Datomic! đ
Our CTO doesn't just want to throw in any new shiney toy (and as you know, devs love their toys)
If you want an accounting trail for fraud etc, Datomic is a perfect match. If you want fancy searching, ES is great. It's why we use both MySQL and ES. We "publish" member profiles into ES every time one changes, so we can do member searches of profiles (typical dating stuff). We also keep an audit trail of all changes to key parts of a member profile.
We talked to Cognitect about our use case and some parts were a perfect fit for Datomic and other parts were totally not appropriate. We didn't want to run both Datomic and MySQL so we chose to just run the latter. But we would have needed a dedicated search service on top of both of those anyway -- and we were using Transparensee's Discovery engine for years, before we switched to ES.
Out of curiosity (and as a fact to include in future decisions), what was it that was OK in MySQL but totally inappropriate in Datomic? Has it to do with the lack of excision in D. Cloud or st. else?
@U0522TWDA We have some datasets that are extremely large -- beyond Datomic's reasonable size range at the time -- and we have some very high write datasets, which doesn't match Datomic's model. Datomic would be a perfect match for some of our datasets, but not everything.
thank you!
they only thing they want to know is finding something by an id (of which the stuff was created at), and perhaps seraching inside notes to pull back the bigger picture.
We use Elastic Cloud for our ES setup. About $900/month for what we're doing, but it can be a lot cheaper if your data volume and search traffic is lower.
yeah, we use http://elastic.io too
(or a lot more expensive if your volumes/traffic are higher!)
I'm going to have a ponder - in the end, it's really a business decision, so I have to present to them some options
My gut, based on what you've described, is that Datomic Cloud + Elastic Cloud might be the sweet spot...
FYI I heard from two devs that are very fond of Clojure that if they had to choose between the language and Datomic, they would pick Datomic. It is, presumabely, such a game changer.
Also, I enjoyed a lot https://augustl.com/blog/2018/datomic_look_at_all_the_things_i_am_not_doing/ and https://augustl.com/blog/2018/datomic_look_at_all_the_things_i_am_not_doing_cont/ For persuading business about Datomic, have a look at https://engineering.telia.no/blog/talk-exploring-four-hidden-superpowers-of-datomic and the resources it links to. The only problem with Datomic Cloud (contrary to on-premise) I have experienced is missing excision, i.e. the ability to delete old data. That is bad for GDPR but perhaps good for your use case.
in jdbc.next
with psql
there an easy way to convert a pgObject
returned by agg_array
into a hashmap, my feeling is no because .getType
doesnât return the schema it just returns the table name
@tavistock Have you read https://cljdoc.org/d/seancorfield/next.jdbc/1.0.13/doc/getting-started#working-with-additional-data-types and the sections it links to? It sounds like you want to extend ReadableParameter
to that type perhaps?
yea, i am using ReadableColumn
to implement the pgObject
conversion, whenever you use json_agg
or the like it returns a pgObject
with a type of "json"
and whenever you use array_agg
it returns a pgObject
with a type of table name as a string. I was wondering if there was a way that other people were using to covert the latter pgObject
into a hashmap but i canât think of a way that it would be possible to do that.
to give an example in psql:
select COALESCE(array_agg(b) FILTER (WHERE t.id IS NOT NULL) as bs, '{}'), a.id
from a
left join b on b.id = a.b_id
group by a.id;
the bs
would be a list of pgObject
s with a getType of âbâ and getValue of â(1,\âexample\â)â
Hmm, PostgreSQL is a tricky beast with all its custom types. Nearly all of my maintenance headaches on clojure.java.jdbc
and next.jdbc
come from PG users đ
There are a few PG-specific libs out there that handle extensions to clojure.java.jdbc
I think -- maybe one of those will give some insight into how to deal with this?
(I don't use PG myself, precisely because of all this sort of pain!)
thanks, ill look and see if the approaches other people have taken for pg and clojure.java.jdbc
will help me out, thanks for you work on jdbc.next
everything so far has been perfect and well documented, so much so that the only problems i ever run into is pgObject
stuff being weird
@tavistock I'm not exactly following your questions, but here is how I coerce between clj/edn and postgres....