Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Datomic is Free

blog.datomic.com

Post reply on HN
Print view View original

351–360 of 436 posts

Re: Datomic is Free

#351

Post by robertlagrant »

foobiekr wrote: post #74
NovemberWhiskey wrote: post #55

Earlier quoted context omitted.

I think the point is that treating your database as an arms-length, RPC component that's independent from your "application" isn't necessarily the only pattern.

Strong agree. there are vast, massive cost savings and performance advantages to be had if the model is that a shard of the dataset is in memory and the data persistence problem is the part that's made external. The only reason we are where we are today is that doing that well is hard.

Is this not the case already? Database drivers (or just your application code) are allowed to cache results if they like. The problem is cache invalidation.

Re: Datomic is Free

#352

Post by augustl »

spariev wrote: post #336
augustl wrote: post #223

Earlier quoted context omitted.

It depends! If you want to lazily walk data, you can read directly from the index (keep in mind, the index = the data = lives in your app), or use the index-pull API which is a bit more convenient. However, if you want to paginate data that you need to sort first, and the data isn't sorted the way you want in the index, you have to read all of the data first, and then sort it. But this is also what a database server…

Yep, I am well aware of these specifics and workarounds, but in general case where is no general solution to the question asked here, for example [0]. And for big datasets with complex sorting it will take some effort to implement a seemingly simple feature. Guess it is just one of the tradeoffs, as while some features Datomic has out of the box are hard to replicate in RDBMS-es, things like pagination which are ofte…

Interesting link, thanks for posting!

Datomic's covering indexes are heavily based on their built-in ordering, and doesn't really have much flexibility in different ways to sort and walk data.

Personally, I'm a fan of hybrid database approaches. In the world of serverless, I really enjoy the combo of DynamoDB and Elasticsearch, for example, where Dynamo handles everything that's performance critical, and Elasticsearch handles everything where dynamic queries (and ordering, and aggregation, and ....) is required. I've never done this with Datomic, but I'd imagine mirroring the "current" value of entities without historical data is relatively easy to set up.

Re: Datomic is Free

#353

Post by javajosh »

gleenn wrote: post #284
greg7mdp wrote: post #215

Earlier quoted context omitted.

This? https://www.youtube.com/watch?v=aSEQfqNYNAc

Yes, this hit home so hard. All objects are bespoke mini languages that add little to no value and simultaneously make it hard to remember and hard to use. Just use maps!

Constraints always have value. Without constraints programmers are confronted with the naked complexity of mapping between the set of all possible states of N bits which is (2^N)!.

Re: Datomic is Free

#354

Post by JohnBooty »

twic wrote: post #342
JohnBooty wrote: post #313

Earlier quoted context omitted.

Yes, although AFAIK those hidden MVCC columns (xmin, xmax?) aren't very usable from an application standpoint -- the obsoleted rows only hang around until the next VACUUM, right? I realize you're not claiming those columns are useful from an application perspective. Just curious to know if I'm wrong and they are useful. Because as I understand it, the selling point of Datomic is their audit trail functionality and th…

Oracle lets you use the MVCC data to query past states of the database, called "flashback": https://docs.oracle.com/en/database/oracle/oracle-database/2... You can configure how long the old data is kept: https://docs.oracle.com/en/database/oracle/oracle-database/2... Worked examples: http://www.dba-oracle.com/t_rman_149_flasbback_query.htm

Wow, super informative. Thank you so much.

Re: Datomic is Free

#355

Post by JohnBooty »

jwr wrote: post #344
JohnBooty wrote: post #315

Earlier quoted context omitted.

Yes. Postgres such a reliable and known quantity that IMO it should be the default choice for just about anything. Don't misunderstand me. There are plenty of times when something else is the right choice. I'm just saying, when I have a say in the matter, folks need to clear that bar -- "tell me why tool xyz is going to be so much better than postgres for this use case that it justifies the overhead of adding another…

> Postgres such a reliable and known quantity that IMO it should be the default choice for just about anything. This is being repeated so often. And yet — the above is true, IF (and that's a big if for some of us) you are OK with having your database on a single machine. If you want a distributed database with strict serializability, where some nodes can go down and you still get correct answers, Postgres is not it.

Totally agree. That's really my thinking as well. Default to Postgres unless you have a reason not to choose it, and a need for distributed serializability is one of those cases where Postgres is an easy "nope, not suitable."

But I've also been burned by people reflexively reaching for $SHINY_NEW_TOY by default, when really there is no need. Architects and senior-level devs are the worst offenders. They throw a bunch of needlessly buzzword-compliant infra at a problem and then move on. They have the time and freedom to learn $SHINY_NEW_TOY well enough to MVP a product, but then the project is passed on to people who don't have that luxury.

I feel like there's a progression that often happens:

1. Early engineers: stick to Postgres or another RDBMS because it's all they know

2. Mid-stage engineers with "senior" in their title for the first time: reach for $SHINY_NEW_TOY

3. Late-stage engineers: stick to Postgres because it's something the whole team already knows and they recognize the true long-term cost of throwing multiple new bits of software infra into the mix

Re: Datomic is Free

#356

Post by svieira »

bsaul wrote: post #339
svieira wrote: post #188

Earlier quoted context omitted.

> which also had some ability to run your client as a cluster node that you alone get to query FoundationDB does this as well.

Do you have a pointer to some doc explaining how to do that in foundationdb ?

https://blog.the-pans.com/notes-on-the-foundationdb-paper/ is one:

> Client (notice not Proxy) caches uncommitted writes to support read-uncommitted-writes in the same transaction. This type of read-repair is only feasible for a simple k/v data model. Anything slightly more complicated, e.g. a graph data model, would introduce a significant amount of complexity. Caching is done on the client, so read queries can bypass the entire transaction system. Reads can be served either locally from client cache or from storage nodes.

Re: Datomic is Free

#357

Post by askonomm »

robertfw wrote: post #308
askonomm wrote: post #257

Earlier quoted context omitted.

As far as the metrics state, Clojure never faded away. It's on an upward trajectory still, albeit slowly. Perhaps it faded away in terms of "HN hype of the day". That said, I've been (and currently am) a Clojure engineer for the past 5 years and loving it. Quite a lot of jobs out there, more and more each time I look, healthy ecosystem and friendly community. It doesn't hurt that it's the most paid programming langua…

The jobs seem to be pretty available in Europe, but I've been struggling to find Clojure work over here on the west coast of North America. I've had to bite the bullet and am looking for work in other languages now, though I'd really rather stay in the ecosystem.

Are you active on the Clojurians Slack channel? On #jobs and #remote-jobs channels every now and then a US job pops up there. You can also post on those channels that you are open for work, might help. I'd also check out some EU job offers (unless the salary is way lower compared to your location) because there are companies that do async and wouldn't care for timezones as much.

Re: Datomic is Free

#360

Post by foobiekr »

bombolo wrote: post #341
foobiekr wrote: post #74

Earlier quoted context omitted.

Strong agree. there are vast, massive cost savings and performance advantages to be had if the model is that a shard of the dataset is in memory and the data persistence problem is the part that's made external. The only reason we are where we are today is that doing that well is hard.

If it's in memory you must live with the fact that it might be gone at any moment though.

Hence "the data persistence part."
Post reply on HN