Call me crazy but I’m planning to Fork wordpress.
I’m planning to swap out MySQL for Apache Cassandra. Call it ambitious but I’m planning to devote a chunk of time over the next few months.
In any case my question is:
I’m trying to aim to keep plugins working… In essence any plugin that doesn’t require their own table should be able to work. Thats the plan, can anyone suggest an approach to handling queries, effectively allowing me to parse queries from plugins.
Only plugins though, the plan is to have all wordpress core core queries removed for Cassandra api calls…
how far along are you at with this effort? I’m thinking of doing the same thing, so I’m willing to help.
Def. not an experiment for us. My team needs to run wordpress on lots of computers and we really don’t care about broken plugins, those can be fixed to implement a DB interface when it comes to creating their entities, the gains of being able to scale horizontally without dealing with mysql and configuration issues are enormous, no single poitn of failure, faster response times, and you have a platform on which you can think of more interesting services on top of wordpress.
I find it crazy that the automattic doesn’t really show much interest about DB independence, maybe they have a deal with mysql that prevents them from this, but oh well, they’re GPL nazis, if they’re not with us, then we can fork them, I’m sure all the major plugins will be re-implemented aswell to be supported on noSQL dbs.
Just to add to this as I randomly found this topic, there is this project:
I’m also very interested in this area as my problems with scaling WordPress ALWAYS come from MySQL.
Seems that after few days of coding I’ve just got something which could be roughly “proof of concept” for migrating WordPress from MySQL to NoSQL (say Mongo). I think the same approach could be used also more in general (SQL to NoSQL translator).
The idea is to prepare additional declarative “tables to collections” mappings. Then use those mappings to process MySQL/SQL inserts into NoSQL/Mongo updates.
Going further – the same mappings can be then used to translate also deletes and selects (joins also can be handled using some helper cache stored in nosql as a document).
The effect should be WordPress going on SQL with no significant change (apart from adding some small SQL translator layer). Performance overhead could be minimized by creating additional SQL cache that will simplify SQL parsing.
Something similiar found here:
Anyone interested ?