5 ms·

Wordpress really screwed up by having a schema-less database. Everything in the database is a key-value pair. This means actual relational operations now need

Wordpress really screwed up by having a schema-less database. Everything in the database is a key-value pair. This means actual relational operations now need to be performed in PHP, instead of letting the RDBMS handle it. This significantly slows down the CMS, and so you have 1-2 second page response times. Meanwhile, my Django sites have response times in the 10-20ms range. (And that's without caching.)

xrstf 10y ago
"Everything is a key-value pair" is flat out wrong[1,2]: There are four key-value tables (commentmeta, postmeta, termmeta and usermeta), but most of the meat of Wordpress is stored in regular tables. [1] https://github.com/ronaldbradford/schema/blob/master/wordpress.sql https://github.com/ronaldbradford/schema/blob/master/wordpre... [2] https://codex.wordpress.org/images/2/25/WP4.4.2-ERD.png https://codex.wordpress.org/images/2/25/WP4.4.2-ERD.png [EDIT: Corrected myself about the number of KV tables]
- mgkimsal 10y ago
  if you're just using WP as a blog engine only, with basic functionality, you're fine. that's what it was built for, and shines. wp_options is a key/value table, and seems to be abused a lot. storing "transient" data in wp_options - what's up with that? why not at least have a 'transient' table, separate from the table that stores my ... options? and... when you've got plugin systems that store everything in postmeta... it's hard to do "normal" relational queries. woocommerce seems to be a good example of this - order info in postmeta? "find all orders in tennessee with more than $10 tax" can only be done with multiple self-joins on wp_postmeta. Perhaps they shouldn't have built it that way, but in my experience most plugin authors use what's provided, and what's provided makes them jump through hoops to do basic stuff, and is not well suited for larger scale apps (but people get suckered in to it anyway because it's "easy to get started"). Who do you blame for these decisions/mistakes? WP? Plugin authors? End users?
  - xrstf 10y ago
    I see your point and share your pain about key-value tables in SQL systems.
- mozumder 10y ago
  Those 4 tables are where all the add-on data goes, for anything that's not a blog. That's where the meat is. Literally, if you're an e-commerce deli.
clifanatic 10y ago
> Everything in the database is a key-value pair. Isn't that the crux of the whole NoSQL "revolution"?
- mozumder 10y ago
  Which is why no one should ever use NoSQL.
- pluma 10y ago
  Only if you conflate "NoSQL" with "pretend everything is Redis". That's why the term "NoSQL" (or even worse: "non-relational") is often pretty much useless: many people think it refers to one category of databases like SQL/relational does.
onetwotree 10y ago
Putting even a very short lived cache in front of it basically removes the issue. But perhaps asking people to understand, for example, nginx micro-caching, defeats the purpose of WP. I'm not terribly concerned about WP performance, it's just a blog, after all - it's the security issues.
busterarm 10y ago
I wiped the caches on my largest recent Wordpress (very complex, post2post links and all archive pages including home page are generated via lookups to metadata tables) site and the response time was 28ms.

xrstf 10y ago

"Everything is a key-value pair" is flat out wrong[1,2]: There are four key-value tables (commentmeta, postmeta, termmeta and usermeta), but most of the meat of Wordpress is stored in regular tables. [1] https://github.com/ronaldbradford/schema/blob/master/wordpress.sql https://github.com/ronaldbradford/schema/blob/master/wordpre... [2] https://codex.wordpress.org/images/2/25/WP4.4.2-ERD.png https://codex.wordpress.org/images/2/25/WP4.4.2-ERD.png [EDIT: Corrected myself about the number of KV tables]

mgkimsal 10y ago
if you're just using WP as a blog engine only, with basic functionality, you're fine. that's what it was built for, and shines. wp_options is a key/value table, and seems to be abused a lot. storing "transient" data in wp_options - what's up with that? why not at least have a 'transient' table, separate from the table that stores my ... options? and... when you've got plugin systems that store everything in postmeta... it's hard to do "normal" relational queries. woocommerce seems to be a good example of this - order info in postmeta? "find all orders in tennessee with more than $10 tax" can only be done with multiple self-joins on wp_postmeta. Perhaps they shouldn't have built it that way, but in my experience most plugin authors use what's provided, and what's provided makes them jump through hoops to do basic stuff, and is not well suited for larger scale apps (but people get suckered in to it anyway because it's "easy to get started"). Who do you blame for these decisions/mistakes? WP? Plugin authors? End users?
- xrstf 10y ago
  I see your point and share your pain about key-value tables in SQL systems.
mozumder 10y ago
Those 4 tables are where all the add-on data goes, for anything that's not a blog. That's where the meat is. Literally, if you're an e-commerce deli.

clifanatic 10y ago

> Everything in the database is a key-value pair. Isn't that the crux of the whole NoSQL "revolution"?

mozumder 10y ago
Which is why no one should ever use NoSQL.
pluma 10y ago
Only if you conflate "NoSQL" with "pretend everything is Redis". That's why the term "NoSQL" (or even worse: "non-relational") is often pretty much useless: many people think it refers to one category of databases like SQL/relational does.

onetwotree 10y ago

Putting even a very short lived cache in front of it basically removes the issue. But perhaps asking people to understand, for example, nginx micro-caching, defeats the purpose of WP. I'm not terribly concerned about WP performance, it's just a blog, after all - it's the security issues.

busterarm 10y ago

I wiped the caches on my largest recent Wordpress (very complex, post2post links and all archive pages including home page are generated via lookups to metadata tables) site and the response time was 28ms.