5 ms·

That is just incredible. Just a rant, I test multiple databases every 6 months and I think that MySQL is unfairly treated because of Oracle acquisition. For my

by bratao 4y ago

That is just incredible. Just a rant, I test multiple databases every 6 months and I think that MySQL is unfairly treated because of Oracle acquisition. For my use-case (store TBs of structured text data, single writer) there is no better (considering performance, replication and compression) than MySQL 8 with MyRocks engine (https://docs.percona.com/percona-server/8.0/myrocks/index.html https://docs.percona.com/percona-server/8.0/myrocks/index.ht...)

dspillett 4y ago
> MySQL is unfairly treated because of Oracle acquisition That, and the history of doing things “wrong” for the sake of performance, and the community banging on about how those of us caring about the data were just being picky¹²³, from long before Oracle came along. myISAM was the default for far too long. > MySQL 8 with MyRocks engine For those concerned about Oracle, there is of course MariaDB which also supports MyRocks. I'm not sure what the current state of play is, but for a while at least MySQL was slower moving than MariaDB, getting CTE support (in production ready releases) a couple of years later for example. --- [1] just implement FKs in your own code! [2] why is 2005-02-31 being sent to the database anyway, why should it check for valid dates?! [3] … you postgres/sql-server/other people are just expecting things the application should deal with, look how fast this is at bulk inserts compared to your “properly”!
- dbt00 4y ago
  http://sqlanywhere.blogspot.com/2008/03/unpublished-mysql-faq.html http://sqlanywhere.blogspot.com/2008/03/unpublished-mysql-fa... for those of us who are old enough to remember actual internet flame culture, this is an amazing late example.
- icedchai 4y ago
  To be fair, MyISAM hasn't been the default since MySQL 5.5... which was released over 10 years ago. I stopped using MySQL in favor of Postgres quite some time ago, so not sure about the current data validation / integrity story, however.
- sroussey 4y ago
  Admittedly, those items could be dealt with at the application later, and for that price you got something very fast. And fast back then meant cheap. Hardware was more expensive than people. It’s reversed now, of course, and we want extra layers and thing to make developers more productive. But back in the MySQL heyday, that was not the case, and I for one am glad something like it was around.
  - dspillett 4y ago
    > those items could be dealt with at the application later That was always one of the arguements, but beyond toy projects or at least beyond a single simple app accessing the DB the application layer is not the best place for that to be implemented. Maybe I'm anal, but there is a point where giving up correctness for performance feels far too icky to me. Also those professing mysql to be the solution back then did so with an almost religious furvour that is always troubling, and if something else threatened their messiah such as sqlite beating it in some benchmark by their own terms, ooh there were hissy-fits and claims of witchcraft!
    - sroussey 4y ago
      It was the difference between website up or website down. So, yeah, lots of emotion in that. I only made ad money when site was up, and thus could eat. Such a direct correlation can make you (well, me in this case) a weirdo. I never talking anything else down so much as give praise to that which saved my bacon. Cloudflare was another one of those things when DDOSes hit.
radicality 4y ago
The Facebook way! Almost all DBs at FB are MySQL (slightly custom) with MyRocks.
- WesleyJohnson 4y ago
  I've never heard of MyRocks. I'm going to look into it some more, but if we're using MySQL as a regular ol' relational database, backing Django, is there anything to be gained from looking at MyRocks? We don't really do document stores, and only have a handful of JSON fields.
  - tehalex 4y ago
    Probably not - unless you are very write heavy and having problems scaling MySQL as-is.
Alupis 4y ago
Unless you need commercial support from Oracle, I just don't see a reason to run MySQL over MariaDB these days. MariaDB has been a drop-in turn-key replacement for us in every case... the MySQL drivers even work with MariaDB as the backend. Nearly everything (perhaps everything) MySQL does, MariaDB has or has had long before MySQL got around to it. Nearly all (perhaps all) commands work exactly the same, which means any support doc or query you might want to run can operate on both without issue. You can even get commercial support for MariaDB from several companies including the very organization that makes it. Not to mention, most of the original MySQL team works on MariaDB. So, other than the folks that don't know or don't care about the history... why would someone go out of their way to choose MySQL these days? Is this the "OpenOffice" effect perhaps?
- mastax 4y ago
  I noticed recently that MySQL has a JSON type that stores as structured binary data, while in MariaDB it's just an alias to MEDIUMTEXT and they provide some functions to operate on it as JSON.
  - Alupis 4y ago
    Very interesting, I was not aware one could (or even would want to) store JSON data in a relational database... The JSON alias was added in MariaDB 10.2.7. This was done to make it possible to use JSON columns in statement based replication from MySQL to MariaDB and to make it possible for MariaDB to read mysqldumps from MySQL. JSON is an alias for LONGTEXT introduced for compatibility reasons with MySQL's JSON data type. MariaDB implements this as a LONGTEXT rather, as the JSON data type contradicts the SQL standard, and MariaDB's benchmarks indicate that performance is at least equivalent. In order to ensure that a valid json document is inserted, the JSON_VALID function can be used as a CHECK constraint. This constraint is automatically included for types using the JSON alias from MariaDB 10.4.3.[1] [1] https://mariadb.com/kb/en/json-data-type/ https://mariadb.com/kb/en/json-data-type/
    - geraldwhen 4y ago
deleted 4y ago
[deleted]

by bratao 4y ago

dspillett 4y ago

> MySQL is unfairly treated because of Oracle acquisition That, and the history of doing things “wrong” for the sake of performance, and the community banging on about how those of us caring about the data were just being picky¹²³, from long before Oracle came along. myISAM was the default for far too long. > MySQL 8 with MyRocks engine For those concerned about Oracle, there is of course MariaDB which also supports MyRocks. I'm not sure what the current state of play is, but for a while at least MySQL was slower moving than MariaDB, getting CTE support (in production ready releases) a couple of years later for example. --- [1] just implement FKs in your own code! [2] why is 2005-02-31 being sent to the database anyway, why should it check for valid dates?! [3] … you postgres/sql-server/other people are just expecting things the application should deal with, look how fast this is at bulk inserts compared to your “properly”!

dbt00 4y ago
http://sqlanywhere.blogspot.com/2008/03/unpublished-mysql-faq.html http://sqlanywhere.blogspot.com/2008/03/unpublished-mysql-fa... for those of us who are old enough to remember actual internet flame culture, this is an amazing late example.
icedchai 4y ago
To be fair, MyISAM hasn't been the default since MySQL 5.5... which was released over 10 years ago. I stopped using MySQL in favor of Postgres quite some time ago, so not sure about the current data validation / integrity story, however.
sroussey 4y ago
Admittedly, those items could be dealt with at the application later, and for that price you got something very fast. And fast back then meant cheap. Hardware was more expensive than people. It’s reversed now, of course, and we want extra layers and thing to make developers more productive. But back in the MySQL heyday, that was not the case, and I for one am glad something like it was around.
- dspillett 4y ago
  > those items could be dealt with at the application later That was always one of the arguements, but beyond toy projects or at least beyond a single simple app accessing the DB the application layer is not the best place for that to be implemented. Maybe I'm anal, but there is a point where giving up correctness for performance feels far too icky to me. Also those professing mysql to be the solution back then did so with an almost religious furvour that is always troubling, and if something else threatened their messiah such as sqlite beating it in some benchmark by their own terms, ooh there were hissy-fits and claims of witchcraft!
  - sroussey 4y ago
    It was the difference between website up or website down. So, yeah, lots of emotion in that. I only made ad money when site was up, and thus could eat. Such a direct correlation can make you (well, me in this case) a weirdo. I never talking anything else down so much as give praise to that which saved my bacon. Cloudflare was another one of those things when DDOSes hit.

radicality 4y ago

The Facebook way! Almost all DBs at FB are MySQL (slightly custom) with MyRocks.

WesleyJohnson 4y ago
I've never heard of MyRocks. I'm going to look into it some more, but if we're using MySQL as a regular ol' relational database, backing Django, is there anything to be gained from looking at MyRocks? We don't really do document stores, and only have a handful of JSON fields.
- tehalex 4y ago
  Probably not - unless you are very write heavy and having problems scaling MySQL as-is.

Alupis 4y ago

Unless you need commercial support from Oracle, I just don't see a reason to run MySQL over MariaDB these days. MariaDB has been a drop-in turn-key replacement for us in every case... the MySQL drivers even work with MariaDB as the backend. Nearly everything (perhaps everything) MySQL does, MariaDB has or has had long before MySQL got around to it. Nearly all (perhaps all) commands work exactly the same, which means any support doc or query you might want to run can operate on both without issue. You can even get commercial support for MariaDB from several companies including the very organization that makes it. Not to mention, most of the original MySQL team works on MariaDB. So, other than the folks that don't know or don't care about the history... why would someone go out of their way to choose MySQL these days? Is this the "OpenOffice" effect perhaps?

mastax 4y ago
I noticed recently that MySQL has a JSON type that stores as structured binary data, while in MariaDB it's just an alias to MEDIUMTEXT and they provide some functions to operate on it as JSON.
- Alupis 4y ago
  Very interesting, I was not aware one could (or even would want to) store JSON data in a relational database... The JSON alias was added in MariaDB 10.2.7. This was done to make it possible to use JSON columns in statement based replication from MySQL to MariaDB and to make it possible for MariaDB to read mysqldumps from MySQL. JSON is an alias for LONGTEXT introduced for compatibility reasons with MySQL's JSON data type. MariaDB implements this as a LONGTEXT rather, as the JSON data type contradicts the SQL standard, and MariaDB's benchmarks indicate that performance is at least equivalent. In order to ensure that a valid json document is inserted, the JSON_VALID function can be used as a CHECK constraint. This constraint is automatically included for types using the JSON alias from MariaDB 10.4.3.[1] [1] https://mariadb.com/kb/en/json-data-type/ https://mariadb.com/kb/en/json-data-type/
  - geraldwhen 4y ago

deleted 4y ago

[deleted]