I just read that Boing Boing has blogged about a new WordPress-based system called Lycueum. The iBiblio project first contacted me it seems about two years ago, so I applaud them for finally getting a release out. From my examination of the code, it seems it’s exactly what WordPress MU is except they’ve modified every SQL statement (what a pain!) to use a monolithic table structure. We tested this approach for MU, but found it was too expensive to scale past a certain point. With monolithic structures you hit a wall based on your hardware. In MU users are divided and can be partitioned easily, for example on WordPress.com we have the users partitioned between 4096 databases, which allows you to scale very cheaply and efficiently to hundreds of thousands and even millions of users and extremely high levels of traffic. It’s unfortunate the Lyceum folks came to different conclusions and decided to focus their efforts on a fork rather than on the core codebase, especially as the massive changes going into WP 2.1 are going to be difficult to merge, but I still wish them the best and I’ll be watching the project closely and picking up anything interesting they do and bringing it back to WP. (Such is the beauty of Open Source. :)) If nothing else, it highlights that the MU site needs a little TLC.
The link to Lyceum is misspelled.
The big advantage to Lyceum though (seemingly anyhow) is that it doesn’t collapse so easily, or just not work, when presented with regular WP themes and plugins. The incompatibilities that MU has, especially with themes, have made it far too much work for many projects I would have liked to have used it in.
Plus it doesn’t seem to need/want Smarty, which I concider a huge plus. Huge. Enormous in fact. I loathe Smarty so damn much….
It would be nice if something could do a full comparison between the two. From your comments it sounds like MU might win in scalability, but they might win on easy of use/installation/modification. Speed? Who knows…
interesting though, very interesting.
Gregory – WPMU hasn’t required Smarty in several months, probably a year by now. It uses bog-standard WordPress themes.
Really? Well in that case the site really needs updating! It still says it requires it.
That is, in fact, what has been keeping me from downloading it again: “argh.. still smarty”
I’ll have to check it out again then, and I would imagine that Matt’s TLC comment has been more than illustrated! 😉
Also it has better compatibility with plugins, since to a plugin the table structure is transparently the same as it is in WordPress. I can’t think of any plugins that don’t work in MU out of the box, even ones that interact with the database.
Matt,
We love WordPress, but as we wrote to you back in the day, we don’t feel that having a million tables is a scalable advantage. I’ve spent enough time with large heavily used mySQL sites to feel certain of that. And then we spent some time with the folks who teach database here at UNC. We got the same answer. Less tables the better if the tables are normalized properly.
Obviously the only way we can ever be sure is if there is a bake-off done by someone other than us at ibiblio or you with WPMU. I think that would be fun. Afterall, we’re all about learning here.
We’ll be passing a million tables in a day or two, so I’ll let you know how it goes. 🙂
Begad, it feels like a horrible flashback to 8 months ago!
We at Plymouth State University have also had some concerns with the many tables. I too have worked on some pretty seriously large MySQL tables that when indexed and queried properly perform fine. One of the areas I have the biggest concern about efficiency in MU is when a new user creates their blog, then posts little to nothing. You still are stuck with all those tables, whereas creating them as new rows in the existing structure would probably lead to very few records.
A final thought, why can’t lyceum modify the DB abstraction layer to shove a blog id into every query automatically, then build the backend admin interface using simple plugins? This way, you could stay nearly 100% base code, and all the plugins should work, the only exceptions (and I’m sure these are what some complained about) are the plugins that have their own tables to store data…
“we have the users partitioned between 4096 databases”
Are you doing this with the base MU code? If so, how? We, here at Plymouth State University didn’t see any way to do this without changes to the code.
I’m probably not alone here … when I say, I’d love to see how you partition the user blog tables N databases, in WordPress.com.
But I understand if that’s not priority #1 anytime soon. 🙂
After scaling Niner Niner to 24+ blogs using stock WP, I think it’s about time we give WPMU a try and use subdomains instead of unique domain names for each blog. =)
I’d like to strongly encourage some TLC (or even just a little more C) on the MU page. A more solid looking page with more up to date info would be an enormous help to me as I evangelize WordPress. Right now, multiple blogs/one install is the *only* thing that’s tempting some institutions towards Movable Type…
I think, the concept of distribution can be still easily achieved in monolithic tables also.. Just replicate the same database, and create a index of which blog is hosted in which table..
So, the scaling is actually a non-issue here.. atleast to my knowledge.
Hey Matt, just a heads up that since the Lyceum project has been discontinued, we’ve developed a method to migrate Lyceum content back to WordPress 3.0. 🙂
That’s cool — haven’t thought about Lyceum in a while. I did always like the name though.