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

Bye Bye Mongo, Hello Postgres

theguardian.com

Post reply on HN
Print view View original

271–280 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#271

Post by dmix »

AlexCoventry wrote: post #269
wftglf wrote: post #242

Earlier quoted context omitted.

Hi! Thanks for your comments. I'm one of the authors of this post. It is the same platform at the moment (just not tagged with editorial tags so it stays away from the fronts), though sometimes the team that approves non-editorial posts to the site can be concerned about us writing about outages and things as it might carry a 'reputational risk', so we may end up migrating to a different platform in the future so we…

Does SecureDrop run on your AWS infrastructure?

It’s probably better if they didn’t answer this question...

Re: Bye Bye Mongo, Hello Postgres

#272

Post by inferiorhuman »

QuinnWilton wrote: post #237
quietbritishjim wrote: post #210

Earlier quoted context omitted.

> IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. The thing I dislike about this type of comment – although I now notice yours doesn't explicitly say this – is the implication that devs don't like SQL because they're lazy or stupid. Well, sometimes that is probably true! But there are some tasks where you need to build the query dynamically…

Elixir's primary database wrapper, Ecto [0], lets you dynamically build queries at runtime, and also isn't an ORM. Here's two examples directly from the docs: # Query all rows in the "users" table, filtering for users whose age is > 18, and selecting their name "users" |> where([u], u.age > 18) |> select([u], u.name) # Build a dynamic query fragment based on some parameters dynamic = false dynamic = if params["is_pub…

> Across all the different means of interacting with a database I have experience with (from full-fledged ORMs like ActiveRecord, to sprocs in ASP.NET), I've found that it offers the best compromise between providing an ergonomic abstraction over the database, and not hiding all of the nitty-gritty details you need to worry about in order to write performant queries or use database-specific features like triggers or window functions.

Ahh Elixir. My favorite language that really just tries so hard to shoot itself in the foot. I'm currently in the protracted process of trying to upgrade a Phoenix app to the current versions. Currently I'm at the rewrite it in Rust and try out Rocket + Diesel stage.

Diesel is... interesting and makes me long for Ecto (which is often used as an ORM although the model bits got split off into a different project).

Re: Bye Bye Mongo, Hello Postgres

#273

Post by sjwright »

mulmen wrote: post #199
acjohnson55 wrote: post #137

Earlier quoted context omitted.

> CMS are a weird application for schemaless. That depends. If the CMS is managing documents that have flexible structures that are tree-like, it might not be such a horrible idea to model that structure in a document instead of relationally.

Document stores might be great for the C but not so much for the MS.

Or to put that in context of a basic data structure:

C = Actual content to be published

MS = User accounts, user permissions, user authentication options, user authentication logging, meta change logs (user X removed tag Y at time Z), behaviour logs (user X viewed revision Y of article Z at time A)... and that's just scratching the surface of a very, very basic CMS.

I'm being generous and assuming articles, tags, bylines, and attached media (with full change history) is all "C".

Re: Bye Bye Mongo, Hello Postgres

#276

Post by thawkins »

KaiserPro wrote: post #169
pjmlp wrote: post #42

Earlier quoted context omitted.

Fashion driven development and not understanding how to actually make use of SQL.

At "large financial news company" we had a "designed for the CV" tag that applied to stupid architectural decisions (of which there were many) One of the biggest and most expensive was using Cassandra to store membership details. Something like 4 years of work, by a team of 40, wasted by stupid decisions. They included: o Using Cassandra to store 6 million rows of highly structured, mostly readonly data o hosting it…

RDD, resume driven development....

Re: Bye Bye Mongo, Hello Postgres

#277

Post by yawaramin »

Thaxll wrote: post #225

It's not a great article tbh, it's well written but it shows the clear lack of knowledge running a backend. The title should be "we didn't know what we were doing so we switched to a managed DB" I mean yeah who knew that blocking NTP therefore time drifting would break everything... For those criticizing MongoDB, Fortnite generates $3B/year and runs on MongoDB, you should tell them it's a mistake and that they should…

Yeah except not every use case is the same. Treating every use case as the same shows, let's see what was it, 'clear lack of knowledge running a backend'.

Re: Bye Bye Mongo, Hello Postgres

#278

Post by quietbritishjim »

QuinnWilton wrote: post #237
quietbritishjim wrote: post #210

Earlier quoted context omitted.

> IMO, the reason is that newer developers faced the choice of learning SQL or learning to use something with a Javascript API. The thing I dislike about this type of comment – although I now notice yours doesn't explicitly say this – is the implication that devs don't like SQL because they're lazy or stupid. Well, sometimes that is probably true! But there are some tasks where you need to build the query dynamically…

Elixir's primary database wrapper, Ecto [0], lets you dynamically build queries at runtime, and also isn't an ORM. Here's two examples directly from the docs: # Query all rows in the "users" table, filtering for users whose age is > 18, and selecting their name "users" |> where([u], u.age > 18) |> select([u], u.name) # Build a dynamic query fragment based on some parameters dynamic = false dynamic = if params["is_pub…

As I said to a sibling response, this is not a substitute for Mongo's aggregation pipeline unless it can do analogous things to Postgres's JSONB fields. For example, can it unwind an array field, match those subrecords where one field (like a "key") matches a value and another field (like a "value") exceeds an overall value, and then apply this condition to filter the overall rows in the table?

Also, one of the benefits of Mongo's API is that it has excellent native implementations in numerous languages (we already use C++ and Python), so a suggestion to switch language entirely is not really equivalent.

Re: Bye Bye Mongo, Hello Postgres

#279

Post by luhn »

quietbritishjim wrote: post #262
aidos wrote: post #226

Earlier quoted context omitted.

I’ll try to avoid a flame war, but since you’re using python, SQLAlchemy allows for composing sql strings.

For it to replace MongoDB's aggregation pipeline, it would need to play nicely with JSONB. Does it do that? This is the thing I'm really missing. For example, if documents in the JSONB column all look roughly like this: { "someArrayField": [ { "key": "steve", "value": 7 }, { "key": "bob", "value": 15 }, ], "someOtherField": [ "whatever" ] } * Can I count the number of entries in someArrayField, summed across all reco…

Yes, you can!

The jsonb_array_elements function is roughly similar to Mongo’s $unwind pipeline op. It explodes a JSON array into a set of rows. From there it’s pretty simple aggregates to achieve what you’re looking for.

I was evaluating Mongo a couple months back to solve roughly the same problems. Eventually discovered Postgres already had what I was looking for.

Re: Bye Bye Mongo, Hello Postgres

#280

Post by myth2018 »

Great article. Such case studies are way more significant contributions to software engineering as a field than the big pile of whitelabel/fanboy articles we see around highlighting advantages of some fancy stuff.
Post reply on HN