Live data from Hacker News

Bye Bye Mongo, Hello Postgres

theguardian.com

361–370 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#361
post #281

Earlier quoted context omitted.

You make it sound like learning SQL is like learning Assembler. It's not that hard. And ORMs exist in every language to abstract it all away. PostgreSQL looks scary because it is a swiss army knife. It has a million different features and data structures. MongoDB does only one thing.

Learning SQL syntax isn't hard, but learning how to properly design relational databases is not something you can pick up from skimming blog posts.

I'd say that this goes for databases in general, not just relational ones.

Which brings us back to the original point: data is hard.

Re: Bye Bye Mongo, Hello Postgres

#362
post #113

Earlier quoted context omitted.

I found it a little funny that NoSQL started becoming popular during at least some of the same years that static typing starting becoming popular (again).

I've noticed that, too. There's an interesting ping-pong effect where a fair number people have flipped from strong typing at the database layer & dynamic typing at the view layer to the reverse — it seems like someone could write an interesting group psychology paper about how that cycle has repeated over the years.

I don't think I'm a Luddite but I always had the feeling I just had to sit out the noSQL / JS everywhere storm.

Re: Bye Bye Mongo, Hello Postgres

#363

Earlier quoted context omitted.

> You make it sound like learning SQL is like learning Assembler It's not that learning SQL is hard. It's that people are inherently lazy. "Learn another thing on top of the thing it already took me a couple of years to learn? No thanks." You seem like the kind of person ready and willing to learn the right tool for the job. From my experience a few years ago on an accredit computing course that covered database admi…

I think what happens (and I have this attitude too) is that "learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language, and the nuances of the specific dialect, and which of the integration tools will work well with your workflow and pipeline. So while "sure I'll just learn SQL" is great for a personal or school project, when you've got to get…

learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language,

SQL is a skill that rewards investment in it 1000x over, in terms of longevity. It has spanned people’s entire careers! What’s the shelf life of the latest JS framework, 18 months at most...

Re: Bye Bye Mongo, Hello Postgres

#364

Earlier quoted context omitted.

I couldn't disagree more, at least in the context of this article. If you have an abstraction layer so high level that app developers can't tell whether they're using MongoDB or PostgreSQL, then they're not able to use any of the advantages of either of those systems. Sure, use an ORM to abstract away the differences between PostgreSQL and MySQL (up until you need to care about them). That's reasonable. But maintaini…

Why wouldn't you be able to take advantage of those systems? I think it's quite the opposite where you can take the advantages without even knowing about it / affecting other parts of the system.

Because of how different they are, taking advantage of them requires using them in specific ways that are also very different. If you have an abstraction layer that hides those differences, it's practically a given that it does so with the lowest common denominator approach, where you get all the flaws of both and none of their unique benefits.

(Alternatively, people find ways to use the abstraction layer such that it produces the desired usage pattern. Of course, then the code is no longer truly portable to another DB, because that same pattern is likely to be a perf issue there.)

Re: Bye Bye Mongo, Hello Postgres

#365
post #183
post #143

Earlier quoted context omitted.

Absolutely - if you don't know SQL and you do know JSON, postgres looks scary and Mongo looks familiar.

Saying "I don't know SQL so I will just use JSON" really misses the point though. SQL is easy. Data is hard. NoSQL products offer to get rid of SQL which includes an implication that SQL itself was the challenge in the first place. The problem then is that you have lost one of the best tools for working with data.

Here is the dirty secret of Mongo: you always have a schema, you just don’t have any tools for validating it or enforcing it or manipulating it.

Re: Bye Bye Mongo, Hello Postgres

#366

My takeaways: 1. Stop. Trying. To. Build. Your. Own. Cloud. A pizza shop doesn't build their own cars to deliver pizzas. 2. There's no such thing as hassle-free anything, unless you are paying someone else to deal with the hassle. Sales teams lie. 3. Justifying an untested idea with "but it's modern technology" is going to backfire. Follow established patterns with good track records. 4. Writing your own in-house beh…

Re 5:

Adding an abstraction on top of DB query won't help much if you are moving from one type of DB to another, say SQL to document, or document to graph.

Re: Bye Bye Mongo, Hello Postgres

#367

Earlier quoted context omitted.

The "this" was referring to dynamically building queries (the GP comment by me) in Ecto (the parent comment by QuinnWilton). What you've said is a non-sequitur in the context of this little discussion. My whole original point is that raw SQL isn't right in all situations, and you appear to be arguing that I just use SQL instead.

I can't speak to every ORM or database interface in existence but ActiveRecord will happily handle Postgres arrays and let you use the built-in array functions just handily without having to write queries by hand. Ecto is less elegant, but you can still finangle some arrays with it. As far as views are concerned, I don't know what to tell you. Sure, you'll probably have to craft the view itself by hand. The result is…

There's also the possibility of using automation to create, update, and manage views. That lets your app be 'dynamic' with regards to new data and new datatypes, but also preserves the performance, debugging, segregation, and maintenance benefits of the underlying DB.

Re: Bye Bye Mongo, Hello Postgres

#368
post #70

Earlier quoted context omitted.

This actually resonates with me, maybe not in the way Ellison intended as I’m not familiar with the context he said it in. A bit off the main topic but the more I revert to just using emacs for some task I previously used a .app bundle or web page for, the more I question how much we the computer industry has just been spinning its wheels for the last 30+ years. I honestly can’t really tell what value WIMP-centric GU…

vi, cvs|svn, C, bash, awk,sed, python and tcl. Linux (rpm based) or FreeBSD. Firefox or lynx. Haven't changed much in 20 years.

[deleted]

Re: Bye Bye Mongo, Hello Postgres

#369

Earlier quoted context omitted.

Cassandra isn't designed for this. Been there, done that. postgres all the way. THe FT use(d) cassandra to store their membership details (6 million rows of largely static, read-only well structured data) The cluster was massive (12+nodes in at least two regions, from memory) slow and was impossible to upgrade reliably. The support from datastax is shite. Backups are not reliable. imports even less so, and you are be…

What were the issues? You're the first person I hear complain about cassandra for this. Agreed that any database can do that type of data at that volume.

its a 50/50 split between terrible design and horrible support.

I've seen cassandra shine when it comes for write optimised loads. Pipe a bucket load of data into gremlin and magic happens.

But thats a specific workload, which is pretty rare, and certainly not suited 999:1 read to write ratio. Thats not cassandra's fault, thats the fault of the idiot that chose it, and the boatload of idiots who carried on and added loads of systems that makes it much harder to migrate away.

Then we come to support. Datastax is the defacto support provider. They make a lifecycle manager, backup/restore tool, and push a load of patches into the main codebase. But it is shit

  o Backups fail silently

  o The only way to make alerts work (ie do an action, rather than create a popup when you log into the ops center) requires work to navigate the API
  
  o Its full of CVEs, which are script kiddy-able

  o migrating data from backups to new clusters was impossible to do without a boat load of manual work, failed 50% of the time

  o restoring from automated backups was impossible until august.

  o it couldn't use instance profiles on AWS until august

  o upgrading to a point release silently breaks backups, _always_ 
Basically I spent the first half of this year QA very expensive software. There are some very very good support people, but there were some terrible ones as well.

Re: Bye Bye Mongo, Hello Postgres

#370

I worked on a large site that used MongoDB. We hundreds of thousands of rows in one specific collection that were used as a log. We couldn't even query it without the whole database crashing. We moved that specific collection to MySQL, no problem and there was virtually no change in the data structure. Both were of course indexed.

You can query hundreds of thousands of rows in a text file on a command line in a raspberry pi with grep and wc.
Post reply on HN