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

Goodbye MongoDB, Hello PostgreSQL

developer.olery.com

Post reply on HN
Print view View original

11–20 of 388 posts

Re: Goodbye MongoDB, Hello PostgreSQL

#11

Post by colinhowe »

IgorPartola wrote: post #4

> Another way of handling this is defining a schema in your models. For example, Mongoid, a popular MongoDB ODM for Ruby, lets you do just that. However, when defining a schema using such tools one should wonder why they aren’t defining the schema in the database itself. Bah. It's like they didn't know that schema-free data stores mean "there is no schema; different objects may have different fields". This is the who…

We have a dataset much larger than RAM (600gb vs 60gb RAM). It's the working set that really matters. Accessing data outside the working set can be slow - unless you have SSDs :)

Regarding consistent/durable: during the past four years, we've not had any problems on this front that weren't caused by us in. We've had an issue that was a misconfiguration on our part where we allowed writes to a server because we pulled it out of a replica set. We also ran out of space on the logging volume once and that caused downtime - but, we didn't have log rotation or anything setup.

In general, we've found the failover very reliable and new primaries have come online without any problems.

That said, schemaless is both a blessing and a curse. Now that Postgres and MySQL have online alter built-in I'd possibly choose one of them if we were starting everything again.

Re: Goodbye MongoDB, Hello PostgreSQL

#12

Post by zrail »

solutionyogi wrote: post #9
pizza234 wrote: post #3

There is a mistake in the article, due to the OP not knowing an arguably basic notion about MySQL. > when defining a field as int(11) you can just happily insert textual data and MySQL will try to convert it. this is dependent on the SQL Mode, which is quite flexible. for example, the STRICT_ALL_TABLES will prevent strings to be inserted in INT fields: mysql> create table example ( `number` int(11) not null ); mysql>…

Personally, I would not use a database which is 'lax' by default instead of 'strict'. What other choices have they made which I need to learn OR it will bite me big in Production?

Example: Inserting strings into a varchar() that are longer than the limit will silently truncate them.

Example: The TIMESTAMP type defaults to the current time instead of null.

There are more, but those are the two that have bitten me in the past (and no I do not use MySQL at all if I can help it)

Re: Goodbye MongoDB, Hello PostgreSQL

#13

Post by jgrahamc »

As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well.

The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid.

And one more thing:

    star = Sequel.lit('*')

    User.select(:locale)
      .select_append { count(star).as(:amount) }
      .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percentage) }
      .group(:locale)
      .order(Sequel.desc(:percentage))
just makes me want to cry. Learn SQL rather than wrapping it.

Re: Goodbye MongoDB, Hello PostgreSQL

#15

Post by pnathan »

solutionyogi wrote: post #9
pizza234 wrote: post #3

There is a mistake in the article, due to the OP not knowing an arguably basic notion about MySQL. > when defining a field as int(11) you can just happily insert textual data and MySQL will try to convert it. this is dependent on the SQL Mode, which is quite flexible. for example, the STRICT_ALL_TABLES will prevent strings to be inserted in INT fields: mysql> create table example ( `number` int(11) not null ); mysql>…

Personally, I would not use a database which is 'lax' by default instead of 'strict'. What other choices have they made which I need to learn OR it will bite me big in Production?

In a previous life, the lax by default approach of MySQL bit us hard on a regular basis; a number of discrepancies vs. reasonable expectation were had. At the time I left, they were working on migrating toward Postgres, and reports suggest they are extremely happy with pg.

Re: Goodbye MongoDB, Hello PostgreSQL

#16

Post by morgo »

pizza234 wrote: post #3

There is a mistake in the article, due to the OP not knowing an arguably basic notion about MySQL. > when defining a field as int(11) you can just happily insert textual data and MySQL will try to convert it. this is dependent on the SQL Mode, which is quite flexible. for example, the STRICT_ALL_TABLES will prevent strings to be inserted in INT fields: mysql> create table example ( `number` int(11) not null ); mysql>…

This is indeed the case. To clarify a little:

- STRICT_TRANS_TABLES is on by default for "new installations" starting from MySQL 5.6 (2013). What this means is that the bundled config files all turn it on.

- Starting from MySQL 5.7, it is a compiled default, along with several other more "strict" options. Effectively making it default to ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER.

I have some sample configuration files to make 5.6 behave like 5.7's strictness. For example: https://github.com/morgo/mysql-compatibility-config/blob/mas...

It does make upgrades harder, so some applications may also need to use a whitelist/blacklist approach to transition: http://www.tocker.ca/2014/09/01/suggestions-for-transitionin...

Re: Goodbye MongoDB, Hello PostgreSQL

#17

Post by serve_yay »

jgrahamc wrote: post #13

As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well. The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid. And one more thing: star = Sequel.lit('*') User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percen…

Gosh, no kidding. (I sorta disagree about ORMs though -- if you're selecting by ID it's monkey work to write those queries, but anything complex, sure, use SQL)

Re: Goodbye MongoDB, Hello PostgreSQL

#19

Post by [deleted] »

jgrahamc wrote: post #13

As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well. The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid. And one more thing: star = Sequel.lit('*') User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percen…

[deleted]

Re: Goodbye MongoDB, Hello PostgreSQL

#20

Post by dkhenry »

super_sloth wrote: post #2

Is there anybody here who has run MongoDB at moderate scale with good results? As in a few terabytes of data, >10k ops/second territory. I've been really disappointed with its reliability and performance in situations where I've been around that.

Yes. When implemented correctly Mongo can scale very well.
Post reply on HN