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

MySQL 8.0 is now generally available

mysqlserverteam.com

Post reply on HN
Print view View original

71–80 of 105 posts

Re: MySQL 8.0 is now generally available

#71

Post by morgo »

kbsletten wrote: post #63
tzs wrote: post #53

I had hoped that the SQL improvements would fix this annoyance, but according to the documentation they did not: create table fib ( a integer, b integer ); insert into fib (a, b) values (1, 0); update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; select a, b from fib; The correct result according to the SQL standard is a == 8 and b == 5…

I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch this with a 10 ft pole because it's not likely to really affect somebody's opinion of MySQL enough to switch, but there's going to be at least one person whose code you'll break. Before you can consider SQL compatibility, you have to keep most-popular-version-of-mysql compatibility.

Hi! Former MySQL Product Manager here. I'm not sure I ever looked at this issue specifically, but you are correct: the burden of breaking backwards compatibility should be high, and supported by major use cases.

To give a similar example, that I did look at: MySQL can enable more standards equivalent identifier quoting (via an SQL mode): https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmod...

To enable that by default would break a lot of applications.

Re: MySQL 8.0 is now generally available

#72

Post by morgo »

kbenson wrote: post #69
kbsletten wrote: post #63

Earlier quoted context omitted.

I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch this with a 10 ft pole because it's not likely to really affect somebody's opinion of MySQL enough to switch, but there's going to be at least one person whose code you'll break. Before you can consider SQL compatibility, you have to keep most-popular-version-of-mysql compatibility.

I agree. If it's desired, use a config setting to make it the default. It was already standard practice in any MySQL database I rolled out to set InnoDB as the default storage engine in the config until it became the shipped default. Like transaction isolation levels, this is something you either set as an administrator for your need, or you let the application setup guide steer you, or you let the application querie…

MariaDB and MySQL have different goals here - MariaDB wants to offer drop-in compatibility for Oracle. MySQL has a core-audience of OLTP apps, that are mostly developed for it specifically.

When designing features, I think it's important to make sure they can benefit the highest number of users possible. For this one, I don't think it can ever be the default because of the burden of backward compatibility. So it is difficult to justify developing it.

Re: MySQL 8.0 is now generally available

#73

Post by evanelias »

ayan wrote: post #58
dancek wrote: post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

MySQL is still a perfectly reasonable choice for massive-scale OLTP workloads. In my mind, a few things MySQL excels at:

* Threaded connection model. Postgres still uses process-per-conn right? This is very painful in situations with high connection churn / fire-and-forget db conns, which are required in some circumstances (heavily sharded environments where keeping persistent connection pools between all app servers and db servers is not practical)

* Ecosystem and experienced talent pool. Among companies with the largest database fleets, a plurality (maybe even a majority) use MySQL, or at least started out on MySQL. This translates to a greater availability of engineers worldwide with experience using and automating giant sharded MySQL fleets, more exposure to MySQL's edge cases, more familiarity with very specific performance characteristics and tuning, etc.

* MySQL's pluggable storage engine API allows flexibility for interesting future possibilities. Facebook migrated part of their MySQL fleet's storage engine from InnoDB (btree-based) to MyRocks (LSM-based) and achieved incredible compression benefits as a result, which translates to huge cost savings, while still being much easier than moving to another DBMS altogether. And AFAIK Postgres does not have comparable compression levels to MyRocks at this time.

* Replication options. I'm sure Postgres will catch up here, but its logical replication support is still relatively new, whereas MySQL has always used logical replication and supports a lot of different topologies and configurations. (Although, I won't cite master-master support as many folks do... it is not a good setup in MySQL and has long been discouraged in the community.)

* InnoDB's use of a clustered index for primary key means that it performs better than a non-clustered storage solution for some (many?) workloads.

Don't get me wrong, Postgres is a wonderful database and absolutely has many qualities and features that MySQL lacks. But it's not the black-and-white situation that some make it out to be.

Re: MySQL 8.0 is now generally available

#74

Post by evanelias »

trizinix wrote: post #14
go_prodev wrote: post #3

Woohoo I've been eagerly awaiting this. I use redshift postgres and SQL server at work and looking to migrate from postgres to MySQL for my personal ML projects. Window functions have been a long time coming and I personally can't wait!

As far as I am aware there is no good reason to not use MariaDB instead of MySQL. The creator of MariaDB, Monty Widenius, was on a episode of the changelog podcast if you want to hear some background as to why.

Monty is also the CTO of the MariaDB Corporation, which is a VC-funded entity. I would fully expect him to sing MariaDB's praises in a podcast.

Large companies have come to a different conclusion, at least so far. Among companies with very large database fleets, there's much greater usage of MySQL and Percona Server than MariaDB.

Granted, Linux distributions have leaned more towards shipping MariaDB by default instead of MySQL. This makes sense given that Oracle is, well, Oracle.

Re: MySQL 8.0 is now generally available

#75

Post by gtowey »

ayan wrote: post #58
dancek wrote: post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

This covers probably the most important reasons to use MySQL over PostgreSQL:

https://eng.uber.com/mysql-migration/

The TL;DR is that PostgreSQL on-disk storage format leads to much higher IOPs for the same workload. For companies running OLTP at scale, the cost differences can be huge.

Re: MySQL 8.0 is now generally available

#76

Post by evanelias »

manigandham wrote: post #60
dumbfounder wrote: post #57

Earlier quoted context omitted.

https://eng.uber.com/mysql-migration/

Uber really just needed a key/value store. MySQL works better when used that way since PostgreSQL has MVCC and can lead to table bloat and compaction issues. I doubt many others ever encounter this issue since picking the correct data store is step 1.

InnoDB also has MVCC. Always has. It just uses a different strategy to avoid the table bloat and compaction issues.

Re: MySQL 8.0 is now generally available

#77

Post by rogerdpack »

dankohn1 wrote: post #55

I think it's disappointing that MySQL is developed in private and then only pushed to GitHub when released. I had noticed that it had not been updated in 3 months: MySQL in the Cloud Native Interactive Landscape https://landscape.cncf.io/grouping=landscape&landscape=datab... Diff showing last commit https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3...

At least it's released at all, but yeah, not a community collab :|

Re: MySQL 8.0 is now generally available

#78

Post by rogerdpack »

ayan wrote: post #58
dancek wrote: post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

I've had count(*) queries take like literally days in Postgres. Want to insert a lot of data? Expect it to cost a lot of RAM. It's got high features but some really rough edges too :|

Re: MySQL 8.0 is now generally available

#79

Post by collinmanderson »

greenhouse_gas wrote: post #64
dpcx wrote: post #35

Earlier quoted context omitted.

"start to think" ? Microsoft went from Windows 2000 to Windows XP then to Vista and then to 7. If people haven't already been thinking that, this isn't what's going to start it, IMHO.

You forgot (especially you're counting consumer Windows, and 2000 was Server windows) 3.1 -> 95 -> 98 (OK. That was normal) -> ME -> XP -> Vista -> 7 (Which should have been 9 If I counted correctly) -> 8 (another OK count) -> 10 -> ? (I don't remember all the Windows 10 releases)

FYI, There always have been actual version numbers under the hood. They kind of messed up 7's number. I guess they had so much trouble changing things from 5.1 to 6.0, they decided another major version bump would be problematic. They apparently changed their minds with 10.

3.10 - 3.1

4.00 - 95

4.10 - 98

4.90 - ME

NT 5.0 - 2000

NT 5.1 - XP

NT 6.0 - Vista

NT 6.1 - 7

NT 6.2 - 8

NT 10.0 - 10

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_vers...

Re: MySQL 8.0 is now generally available

#80

Post by zht »

rogerdpack wrote: post #78
ayan wrote: post #58

Earlier quoted context omitted.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

I've had count(*) queries take like literally days in Postgres. Want to insert a lot of data? Expect it to cost a lot of RAM. It's got high features but some really rough edges too :|

the same would happen in MySQL right? select count(*) does a table scan
Post reply on HN