Lack of access to central sewage system does not necessarily imply a lack of a "normal WC". This figure includes households which use individual sewage systems ending up in septic tanks or cesspools, and is not significantly larger than 20% of the U.S. households that don't have access to a centralized sewer either: https://nepis.epa.gov/Exe/tiff2png.cgi/P1004624.PNG?-r+75+-g... Of course latrines are a thing in rural Russia and, sadly, children do drown in them, but this article does not support your original claim.
There is no advantage: the modern GPU can build thousands of full page resolution fractals per second while SQL takes seconds to produce a hundred by hundred characters ASCII art.
It's just a New Year SQL picture post, something I do every new year on my blog.
However, nested sets is still very expensive to update which may be a deciding factor if your hierarchy is subject to frequent change (like, a folder-like structure with the folders being moved here and there) and you don't need to query for "all descendants" often.
"HDD bound" here means that not all data fits into the cache.
Given the average RAM size on even an entry-level server (some 16 or maybe even 8 GB) and the average size of a database (same 8GB on http://musicbrainz.org/, the largest online music database), I wouldn't claim that it's "most workloads".
If we're comparing anecdotes, the smallest database I deal with on any given day is 50GB. Enterprise applications trap lots of data. I don't know that most of our queries are HDD bound, but a significant portion of them are.
I think while the most performance-critical portion of your data fits in memory you should be alright with this method. The rest of the data can be consumed using normal SQL approach.
Sorry about the awkwardly worded question. What I meant is, what do you actually get from using MySQL? I can understand that a lot of people aren't willing to make a switch to some dedicated KVS, but going through all that effort would seem to require the same amount of time, if not more. So there has to be something about using MySQL that makes it worth using even in this stripped down configuration.
I think the idea is that you store your data in a relational model and access it using SQL. But for things that need to be looked up a lot, and very quickly, rather than tagging on a KV store in front of MySQL, use the method he describes instead.
This way you don't end up duplicating the cache, it is shared between the two different types of lookups. You also don't end up with data inconsistancies. And yet you get the speed that a dedicated KV store would have got you anyway.
Convenience of the complex queries. If you need anything more than a simple key-value access, you'll in fact need to implement the query engine yourself if you decide to use NoSQL.
Note that the author specifically mentioned that they use HandlerSocket for fast key retrievals and SQL for complex queries, and both methods work together on the very same database.
Yes, InnoDB was standalone. But it had it's own SQL parser and things like Stored Procedures as well ;) It was rudimentary, but I don't know if KVS is the best description.
How MySQL and InnoDB talk is very much a K<->V / row based relationship.
All major engines have collations and collation-specific behavior (which can be confusing). However, this one I saved for the next post (with another set of completely unrelated pictures).
All "wrong" queries are wrong in PostgreSQL as well (and #3 won't even parse). The workarounds for #4, #3 and #2 are different for PostgreSQL, the others will work.
