MySQL Raytracer(pouet.net)
pouet.net
MySQL Raytracer
https://www.pouet.net/prod.php?which=83222
25 コメント
Here's a direct link to the youtube video showing the result:
https://youtu.be/U5Tk1H5C4xI?t=75
Okay not bad, but can you implement Doom in MySQL? ;-)
If you can generate this image I’m inclined to say yea (outside of like actually displaying it). I doubt your frame rate would be too good tho
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.ht...)
> 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”!
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”!
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.
for those of us who are old enough to remember actual internet flame culture, this is an amazing late example.
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.
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.
> 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!
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!
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.
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.
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.
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?
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?
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.
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]
> I was not aware one could (or even would want to) store JSON data in a relational database...
Perhaps it's to borrow some elements from data stores like MongoDB, but whilst keeping most of the system based on the typical table/relation principles.
I've actually seen JSON used in PostgreSQL and admittedly I found the approach to be pretty horrible in most cases, performance/functions/syntax regarding the datatype aside.
Yet, I can't say that there aren't valid use cases for something like that, even if generally I'd advise against storing data that you actually want to query in a relational DB inside of JSON. Perhaps that's just because I believe that it'd increase complexity unnecessarily in most cases.
Perhaps it's to borrow some elements from data stores like MongoDB, but whilst keeping most of the system based on the typical table/relation principles.
I've actually seen JSON used in PostgreSQL and admittedly I found the approach to be pretty horrible in most cases, performance/functions/syntax regarding the datatype aside.
Yet, I can't say that there aren't valid use cases for something like that, even if generally I'd advise against storing data that you actually want to query in a relational DB inside of JSON. Perhaps that's just because I believe that it'd increase complexity unnecessarily in most cases.
I use it to store metadata I don’t need to query for the most part.
Saves a lot of time data modeling and managing schemas for that kind of non critical data.
Saves a lot of time data modeling and managing schemas for that kind of non critical data.
I lean on this quite often.
I find it really useful to utilize normal relational db things for 98% of your table and then have a column or two where you can store json objects and run queries for deep nested values equals x and things like json contains such and such value, etc.
I find it really useful to utilize normal relational db things for 98% of your table and then have a column or two where you can store json objects and run queries for deep nested values equals x and things like json contains such and such value, etc.
The Facebook way! Almost all DBs at FB are MySQL (slightly custom) with MyRocks.
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.
Probably not - unless you are very write heavy and having problems scaling MySQL as-is.
[deleted]
The source seems to be rather imperative: https://gist.github.com/remram44/755302174c912a004f8c839f3c8...
Imperative and eschewing of newlines… maybe change the subject line here to “25-line MySQL Raytracer” ;D
This thread is a duplicate of the 2019 thread https://news.ycombinator.com/item?id=21218144
Reposts are ok after a year or so! https://news.ycombinator.com/newsfaq.html
(It was reposted in April 2022 too - https://news.ycombinator.com/item?id=31167205 - but didn't get significant attention. That's the other variable.)
(It was reposted in April 2022 too - https://news.ycombinator.com/item?id=31167205 - but didn't get significant attention. That's the other variable.)
The most advanced MySQL raytracer on the market - https://news.ycombinator.com/item?id=21218144 - Oct 2019 (47 comments)
MySQL Raytracer - https://news.ycombinator.com/item?id=21199895 - Oct 2019 (2 comments)