views:

55

answers:

2

I have been tasked with starting from scratch on the CMS/engine and admin/backend for website for the company I work for.

What we do would be classed as 'quite unique' (though, isn't everyone's situation?) and I am looking at ways I can move towards a better system from something that is downright painful to use.

Our current system provides article, galleries, custom pieces of data (updated on a daily basis) and data from feeds in a structured format (like weather information), as well as also providing forums etc to our members.

There are a few things I am looking to move out of our core app, the forums for one, but most of the other stuff will be rebuilt from the ground up. Currently everything is stored in a MySQL database and its history is quite poor (when I took on the project load times were around 60 seconds per page, and after taking out stupid database calls and model design, has been reduced to an acceptable 0.2/0.3 second per page).

The site its self is built in Rails and there is no intention of changing that, however what I am looking at right now is whether its ideal to look at other database solutions instead of the traditional RDBMS like MySQL.

Considering that most of our content is either structured news items (e.g. a news item with a number of attributes, and then what I would call 'blocks' of different content - text, video embed, images, quotes etc), galleries (text and images) I am wondering if using a document oriented database such as MongoDB is ideal.

In terms of performance I feel that it is comparable to a well designed MySQL system, and considering that the site will be heavily cached (Varnish with ESI for dynamic blocks in the page) the DB times aren't a huge factor.

The other thing with this project is that we want it to be multi-tenanted, being we can host different sites (e.g. same genre (base data formats etc) but different topic) - and it needs to be flexible for the site admin/owners to setup new things themselves (i.e. when a new site is created I shouldn't have to setup a whole new site/server and make code changes etc).

I'm wondering if I am overthinking this too much, or perhaps I am becoming paralized by the 'anticipation' of what I need to do for all of this.

My question, boiled down is: should I consider MongoDB or similar for things which really don't seem to suit a standard DB table format, or am I chasing after what is new and shiny?

Sorry if this is quite ramble-ish...

A: 

What is your performance target? With proper caching, fast frontend + MySQL could have no problems with serving 200-400 requests per second (<0.01seconds per request).

If you use heavy frameworks and crap code, you will get 5 requests per seconds no matter how fast is underlying storage.

So my suggestion - use what is EASIER and write proper code, avoid heavy frameworks.

BarsMonster
A: 

Yes, you are.

I am doing a similar CMS type website right now and I had the same decision about which DB to use.

My conclusion was basically to stick with what I know: PHP and mySQL/Postgres. Yeah, Mongo or another noSQL might be a better fit for the data but it'd take me time to learn how to install and use them and frankly, unless you have a massive amount of traffic, mySQL/Postgres will not cause performance issues. If you keep your DB code abstracted then you can drop in Mongo/whatever much later if you need to.

As BarsMonster said, a good HTML caching scheme at the front end will reduce your DB usage massively. Use memcached if you need to.

Keep it simple, use the tools you know and ship it.

Steve Claridge