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

21–30 of 388 posts

Re: Goodbye MongoDB, Hello PostgreSQL

#21

Post by morgo »

zrail wrote: post #12
solutionyogi wrote: post #9

Earlier quoted context omitted.

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)

See my other comment in this thread RE: string truncation (strict sql mode will default on in MySQL 5.6/5.7).

It is possible to change timestamps to default to Null. For backwards compatibility, the previous behavior defaults:

http://dev.mysql.com/doc/refman/5.7/en/server-system-variabl...

Re: Goodbye MongoDB, Hello PostgreSQL

#22

Post by jgrahamc »

[deleted] wrote: post #19
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]

There's quite a bit more I can do with Arel than I can do with raw SQL, especially if I'm already in Ruby. So... no thanks. :)

Instead of making a statement like that... educate me. I'm very happy to learn about new technologies. What extra, interesting things can you do with Arel that aren't possible in SQL?

Re: Goodbye MongoDB, Hello PostgreSQL

#23

Post by pizza234 »

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?

It's not so easy.

MySQL has a large legacy of being used as a very-immediate-although-somewhat-toy database at its roots.

For example, in absolute terms, I would find much more troubling the usage of non-transactional tables, justified by meaningless microbenchmarks, which has been somewhat common for some time.

Nowadays MySQL is definitely reliable, and it has a much more expert surrounding culture than the past, so if a person/company is willing to put time and knowledge, it's a reasonable choice.

I don't find automatic conversion so damaging that people should stay away just because it's default.

When you reach some level, you definitely need to have a relatively intimate knowledge of your tools, and at such point, one is far from the "defaults".

Re: Goodbye MongoDB, Hello PostgreSQL

#24

Post by JonnieCache »

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…

Sequel is the best ORM I've ever seen or used, but that is (probably IMO) not a good application of it.

It gives you total choice over what level of abstraction you want, so this is a particularly egregious use of it, being as nothing about that query is dynamic :)

You can use it purely to execute handwritten SQL queries loaded from files, or stored procedures, or any level of abstraction between raw SQL and the monstrosity you posted. The model layer is totally optional and is built cleanly on top of the query/relational layer, not inside of it.

The thing is a fucking work of art to be honest. The design shows impeccable taste, ruby's more exotic features are deployed only when really needed, everything is so clear, especially if youre used to activerecord.

BTW also the developer is super helpful and pops up everywhere to answer questions.

Re: Goodbye MongoDB, Hello PostgreSQL

#25

Post by quackerhacker »

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.

I've been using mongo on 39M+ records (tracking financial tick data) across 73 assets (collections) and my queries take anywhere between 2-3mins depending on complexity.

You can always run db.currentOp() in the mongo shell to see what process is taking forever as well.

Let me clarify why though, there methods of optimizing a query by adding another field, but since I have to traverse my records with the sort() cursor my queries take that long.

Re: Goodbye MongoDB, Hello PostgreSQL

#26

Post by beering »

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?

You can subtract two DATETIME columns in MySQL and it will not generate any warnings. It will give you an answer that probably is within the ballpark of the actual time difference but isn't the actual time difference.

Re: Goodbye MongoDB, Hello PostgreSQL

#27

Post by Pxtl »

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…

I use Entity Framework as an ORM and I have to say I like it. As much as there have been a lot of false-starts related to trying to reinvent SQL, I think Entity Framework hits many of the right notes for me:

1) All my code lives in Visual Studio with compile-time type-checking. No maintaining stored procedures outside of my main codebase, no mucking about with strings. And because Entity Framework puts the Select after the From clause, I even get good intellisense on column-names.

2) I can quickly shift code into being in-memory queries from database queries.

3) While it's a little muddy mixing SQL and C#, there are places where C#/EF's syntax is so much more brief and clean since it's hyper-aware of relationships. For example, instead of writing 2 joins to get the country of a user, I can say User.Centre.Country.

Of course, the Entity Framework is adding a layer of complexity to my work - you still have to know what's going on in SQL, and that mental overhead is a downside. But it pays off.

SQL is a brilliant language, and that's why it's stood the test of time in spite of its advanced age.

But seriously, it has a lot of bad flaws - it's often difficult to make reusable components in SQL like you can in other platforms.

The underlying relational algebra is brilliant. That's why I like ORMs - they admit that SQL is ideologically beautiful, but the SQL language itself could use some loving.

Re: Goodbye MongoDB, Hello PostgreSQL

#28

Post by jv22222 »

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…

I agree, using ORMs and such hide the real SQL and make it much harder to optimize by using explains etc.

Re: Goodbye MongoDB, Hello PostgreSQL

#30

Post by ak217 »

Ixiaus wrote: post #6
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.

I came into a company that was attempting to use MongoDB for their soft-real time time-series data (I would consider it between low and medium scale) and it was atrocious, in too many ways. It doesn't scale without tremendous effort and implicit schemas are a very dangerous thing to introduce into your application, they're insidious, and require enormous diligence in the application to codify the schemas (I would onl…

What were the more appropriate solutions?
Post reply on HN