Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Up until recently I was using mongo to try and stem to tide of massive MySQL upgrades to system servers, however, after reading this:

I have halted production of a mongo version of my site until mongo would gain more stability.

Some have suggested I use the _change within couche DB to create a new mongo object which would solve the main issues within mongo db atm but I'm not sure about it.

I have looked into other DB's such as redis and Cassandra but I have since ditched Cassandra as you have to design for your queries and that's just too restricting for my site (bad modulisation). I'm not really looking for joins etc, I'm just looking for the ability to search within a row instead of just the columnfamily id's as it can make programming quite hard when trying to add new functionality. It would be great for a search engine or something but not so good for a real website like facebook in it's entirty (instead of just in its mail search).

I was wondering what experiences people on here have had with trying to get a workable solution to the SQL speed issues. Is there a silver bullet db for it all or is it just a case of gritting your teeth with MySQL or another SQL db if you want reliability?

Maybe a cross between a form of caching and SQL (I noticed facebook uses heavy caching on their wall pages etc...probably why).


share|improve this question
up vote 0 down vote accepted

You haven't really given any idea of the scale of your site which makes a huge difference to what technology/method is appropriate.

At any rate nothing is going to be a magic bullet. Most of the things you are mentioning are about making large scaling possible rather than avoiding scaling at all.

Even using something like memcached in front of the db needs a slightly different way of thinking to get the full benefit of it. One of the first things you need to do (and there can be great savings if you haven't already) is to look at and optimise the sort of queries you are making.

share|improve this answer
Same sort of site if not larger (load wise) than facebook (upto 2 million+ users with 1 or 2 tables stretching on for 10-30 million rows), it's an intranet site but does have outside connections to specific people/companies. Scaling is essential (that is why I am not avoiding it), that is the problem I am having with SQL after about 25 servers it does not scale well. No matter how optimised I query it still is slow and cumbersome compared to something like mongo. – Sammaye Jul 9 '10 at 11:39
Well i have to admit, facebook size is a bit over my depth :P But with the last reports they were running 1,800 mysql behind 800 memcached servers and scaling them seems to be mostly a case of partitioning the data inventively. There's quite a lot of info about their and others approach on – JamesRyan Jul 10 '10 at 12:52
Wow facebook still use MySQL...didn't expect that. I spoke with mongo and they were saying they'll have everything fixed by 1.8 so I've decided I'm gonna wait for them to get it fixed and stick with mongo. thanks, – Sammaye Jul 12 '10 at 8:11

What is your issue with Mongo exactly? You will need to make backups anyway. It now supports replica sets so you are really not tied to a machine failure.

If you are using 25 servers now, you could easily run a replica set of a few servers and not have a single point of failure.

10-30 million rows is really not a lot. Especially since with a noSQL solution you can probably consolidate a few rows into single records. If you have 2 million users, it is even possible most of their data will fit into single records. (4 mb limit is a lot)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.